Within XP testing is of distinguished importance. In addition to acceptance tests, which are specified by the on-site customer, XP employs unit tests, which are written by the programmers.
Unit tests can be used for different purposes. Most of the time they are created while doing pair programming. After a unit test has been written, the source code of the system is altered until the unit test runs successfully.
Unit tests can have different scope. They may test single methods, but also entire classes or subsystems. Typically, unit tests are created as mentioned, however, there are other scenarios, where they are applicable.
When writing unit test, you quickly discover that there are things you are doing over and over again. For each test a couple of test objects have to be created, then a series of methods is called, and finally all the test objects have to be deleted. The latter will be done automatically by most of the programming languages, e.g. Java, Smalltalk, C#. But, if you have created some entries in a database table, these will not be removed automatically.
Another commonality among tests might be that some of them can/should be run against the same set of test objects. In this case it would not make a lot of sense to create these test objects for each test.
Furthermore it would be nice, if you could run just a single test or a group of tests, a test suite. And it would be even nicer, if you could run them from both a graphical user interface or a command line (shell).
For all these issues there is a very cost effective answer: the xUnit test framework. The letter "x" is a place holder for different letters, representing different programming languages. JUnit is the test framework for Java. SUnit is the one for Smalltalk. NUnit is for Microsoft .NET applications, HTTPUnit for HTML applications and so on. A unit testing framework for C# is available for free as a download from the csunit web site.
So, if you are writing unit tests, you should definitely take into consideration using one of the xUnit test frameworks.
From time to time it can happen that a user of the system detects a defect (even XP is not perfect in this respect!). In this case fixing the defect will be scheduled as a seperate task for the next iteration. In urgent cases it would even be added immediately.
It is important to first write a unit test, which reproduces the defect. Theoretically this unit test should have been written by the pair who implemented the functionality. However, who of us is perfect?
After the unit test has been written - it fails, of course - the source code will be altered until the unit test runs successfully. We are back to the normal process. Once all unit tests and all acceptance tests run successfully the modified source code can be integrated, and the new version of the system becomes available.
© Copyright 2001-2002 by Manfred Lange, All rights reserved. Terms of use.
Last change: