Why Write Test Code?

Why bother writing code to test something that the developers will test themselves while developing and that the main testers will be testing anyway? Simple answer: to improve the overall quality of the end product and the maintenance of that product.

What this means in practice is that the developer will be writing some test code as well as the application code. Of course, this is going to take longer than just writing the application and no test code ... or is it? There are other aspects involved with development and testing that having test code can benefit from.

Case 1
Let's first consider what happens when there isn't any test code written ...

The developer creates some functional area of an application and tests this creation by hand. So far, so good ... and now the developer moves onto the next task which is a new area of funcitonality. The developer finishes polishing off the new code and starts on the manual testing and finds that all checks out OK. Still sounds good right?

What the developer didn't notice is that while creating the new code, they accidentally managed to change some code that is used by the older case and now that doesn't work! When is it noticed that it doesn't work though? If it is right that moment, that means the developer has gone over all of the tests for the first code manually again. This is quite unlikely and what is more likely to happen is that it gets noticed two weeks later when an integration build is made and gone over again, manually (and as the testing is manual it can still easily be overlooked a this stage too and ends up going through to the main testers - which results in further delays in testing). Now, there is a bug to resolve and no idea when the bug was introduced. Some time later, the bug is found, fixed, and then the manual testing beings again ... (go back to start of paragraph and read again)

Case 2
So how can having test code help with this vicious circle? Let's do the same again, but now include writing test code ...

The developer creates some functional area of an application and writes some test code to test this. So far, so good ... and now the developer moves onto the next task which is a new area of functionality. The developer finishes polishing off the new code and writes some test code to test this. The new tests pass and all is good.

What the developer didn't notice is that while creating the new code, they accidentally managed to change some code that is used by the older case and now that doesn't work! When is it noticed that it doesn't work though? Right after the developer then runs the existing regression tests to check that nothing else has been affected by the new code. Now, the developer has a much better idea where the problem lies and can get to the actual bug much quicker. A short while later, the bug is found, fixed, and then the regression tests can be run again ... (carry on with further development)

Once these regression tests are in place, having the confidence and possibility to refactor when needed can be carried out without being afraid of what might break or having to retest the application by hand again. Bug fixes can be made, small additions to some use case can be made, each time running the tests to ensure all was working as it was previously. This benefits both the development and maintenance phases.

When a bug is found in the application, a test case can be written to prove it is there. When the bug has been fixed and the test case passes, you have another test case created and left in place that will ensure that the same bug doesn't creep back in.

Code coverage can be applied to check how much of the application code is exercised during testing and to help build up the test code to provide more (targetted) coverage for the application.

Technical problems that may have crept in are detected quickly and much less likely to end up causing delays in user testing, where testing should concentrate on the business aspects of the application.

So, to summarise ...

Benefits

• re-usable regression test suite
• many test cases can be run quickly
• locating problems more quickly
• confidence and means to refactor
• helps maintenance phase
• code coverage can be used much more effectively
• more value from the test effort
• allow the main testers to test the business aspects of the application

Drawbacks

• takes time and effort to write the test code
• requires commitment from the whole project (drawback?)

Last Updated Monday, November 21 2005 @ 07:38 PM CST; 4,416 Hits