Writing automated tests is a tried and tested way to improve the quality of software. In the initial phase of development, tests help to verify that the code functions correctly. In Test Driven Development, tests are written before the code, so any knowledge about the ins and outs of the implementation won't influence the writing of the tests. After the initial development, as changes are made over time, a comprehensive test suite can quickly point out unintended changes in the behavior of the code, so the bugs can be fixed before the software is shipped. Importantly, the tests are automated, so they are very cheap to run in terms of time.

What do we want from a test suite?

There are a range of properties that are good to have in a test suite.

• It often allows bugs to be pinpointed to a relatively small area of the code base, saving debugging time...

Test Driven Development is a development methodology that encourages you to write tests before writing the code that is being tested. Following it completely strictly means that you never make a functional change to the code (that is, adding a new feature or fixing a bug) until you have a failing test that implementing the feature or fixing the bug will cause to pass.

For those who are not used to writing tests, such a strict methodology can feel quite daunting, potentially unproductive and perhaps fun-spoiling. I can empathize with all three points of view, but at the same time it's worth trying almost everything at least once to see how it works out (though I'm still not so keen on trying a bungee jump).

In this article I'm going to look at the idea of automated testing more generally. I'll share a couple of my experiences of it, then I'll look at some thoughts for giving it a go in your own environment.

=== Why Automate Testing? ===...