The Last Test You'll Ever Write

| Comments

What Makes You Think It Will Work?

  • In production?
  • when the database goes down?
  • If we get ten-times our normal traffic?
  • If an exception is thrown by the confabulator module?
  • If someone doesn’t enter any input at all?
  • If we need to revert our code?
  • In Opera/Safari/Konqueror?

You can add your own predicates to this question, but you get the idea. I find that this is a great principle to follow when building software. This concept glues together all the other kinds of testing we do, but it’s easy to lose sight of it.

Passing unit tests aren’t good evidence that your system will work. They’re good evidence that your code isn’t fundamentally broken, but say nothing for what the end-user might experience.

You still need to verify that your code will integrate properly with other systems, deploy well, and work in it’s live environment.

Better than just unit tests is a combination of automated and human test flavors: unit tests, integration tests, automated browser tests, human-driven testing, and any number of others.

All this testing creates a level of confidence that things will be OK. It’s never really a guarantee, and each team’s mix will vary.

It might be ok for your shop of one to have no automated tests for the one page you manage. You just need to be prepared to click all the links on it every time you make a change.

Your 100-person team building an enterprise portal probably needs a little more automation to achieve the same level of comfort, and so will likely rig some integration tests and browser testing.

Or maybe you just decide that you can and should staff fifty full-time testers to continuously click things.

Whatever the mix, the purpose remains the same: help build confidence that the final product will work.

blog comments powered by Disqus