In days of old, software was developed and then tested. This generates some serious problems since projects are often late leaving testing to be rushed or skipped to ensure the product ships.

Retrospective tests can (for political reasons) be devised to ensure the code passes and can’t help but be based on the product as it is written, not as it was hoped to be. Overall such late testing doesn’t work. The more modern approach is to make testing part of the actual coding process, designing tests as integral to the product design right from the start. Alongside “can we build it?” issues such as “can we test it?” and “what defines a pass?” are tackled. This process helps create robust software and is really helpfully in exposing flaws, not just in the code, but in the design and specification. So good is the process TDD (Test Driven Design) requires that tests and what constitutes a pass are written before the actual coding begins. The product specification is the tests. I must admit my first use of TDD was a sceptical one involving an assignment with the tests already written. All I needed to do was write the library to make the tests work. Of course everything fails from the start (heck, it won’t even compile) but as work progressed more and more of the tests would pass and any changes to the code could be very quickly checked by simply running the tests. I was sold. For developers such automated testing also provides a valuable peace of mind. Most developers want others to check their work and tell them it’s what’s expected and they’ve understood everything correctly. That rarely happens until too late in the day so TDD gives reassurance: what the customer requires is “pass these tests!” and is a fantastic CYA. The automated aspect means that testing can be done frequently allowing recent code changes to be double checked for their possibly unwanted effects. Overall a much better approach. As part of writing some PHP code I’ve used this approach using a library called PHPUnit. If you are familiar with JUnit for Java it’s nearly identical. Tests are written to make use of my PHP code, the tests run and failures shown. A really useful extra is VisualPHPUnit which allows the tests to be run via the browser and the results neatly displayed. Really helpful when developing website code, just make sure the testing code is password protected by your webserver! Unit testing refers to testing portions of the code rather than the whole overall functionality, think of it as quality control for the components used to assemble a car. Of course the ‘component’ can be quite large so unit testing will be at many levels through the software to check assembly has occurred correctly. Testing how the overall software product works from the users’ perspective requires different approaches and tools which I’ll write about one-day :)