20.9. Test-First Programming

An excellent practice promoted by the Extreme Programming (XP) method [Beck00], and applicable to the UP (as most XP practices are), is test-first programming. In this practice, unit testing code is written before the code to be tested, and the developer writes unit testing code for all production code. The basic rhythm is to write a little test code, then write a little production code, make it pass the test, then write some more test code, and so forth.

Advantages include:

• The unit tests actually get written— Human (or at least programmer) nature is such that avoidance of writing unit tests is very common, if left as an afterthought.

• Programmer satisfaction— If a developer writes the production code, informally debugs it, and then as an afterthought adds unit tests, it does not feel very satisfying. However, if the tests are written first, and then production code is created and refined to pass the tests, there is some feeling of accomplishment—of passing a test. The psychological aspects of development can't be ignored—programming is a human endeavor.

• Clarification of interface and behavior— Often, the exact public interface and behavior of a class is not perfectly clear until programming it. By writing the unit test for it first, one clarifies the design of the class.

• Provable verification— Obviously, having hundreds or thousands of unit tests provides some meaningful verification of correctness.

• The confidence to change things— In test-first programming, there are hundreds or thousands of unit tests, and a unit test class for each production class. When a developer needs to change existing code—written by themselves or others—there is a unit test suite that can be run, providing immediate feedback if the change caused an error.

As an example, a popular, simple and free unit testing framework is JUnit (www.junit.org) for Java. Suppose we are using JUnit and test-first programming to create the Sale class. Before programming the Sale class, we write a unit testing method in a SaleTest class that does the following:

For example:

						public class SaleTest extends TestCase
						{
						// ...
						public void testTotal()
						{
						// set up the test
						Money total = new Money( 7.5 );
						Money price = new Money( 2.5 );
						ItemID id = new ItemID( 1 );
						ProductSpecification spec;
						spec = new ProductSpecification( id, price, "product 1" );
						Sale sale = new Sale();
						// add the items
						sale.makeLineItem( spec, 1 );
						sale.makeLineItem( spec, 2 );
						// verify the total is 7.5
						assertEquals( sale.getTotal(), total);
						}
						}
					

Only after this SaleTest class is created do we then write the Sale class to pass this test. However, not all unit testing methods need to be written beforehand. A developer writes one testing method, then the production code to satisfy it, then another testing method, and so on.