Test

Test-Driven Development

Test-driven development (TDD, that includes the sub-practice of test-first development) is a key practice in XP, and is now promoted in several IID methods. An important part of TDD is that there are automated tests for (almost) everything, and most tests (especially unit tests) are written before the code to be tested.

This bears repetition: Unit tests are written before writing the code to be tested, imagining that the code exists.

Further, the tests simply pass or fail. There is no need for human inspection of specific test results. If you have 2,000 unit tests created in the TDD style, it all boils down to one question "Did they all pass?"

A brief programming example is presented to provide a concrete sense of how this key practice works.

Suppose Jill needs to create a Money class (in Java), to support multiple currencies, adding money, and so forth.

Since this is a TDD project, rather than start by writing the Money class, she starts by writing the MoneyTest class, adding one test method.

 public class MoneyTest extends TestCase { public void testSimpleAdd() {      Money m1 = new Money( 12, "usd" ); // ONE      Money m2 = new Money( 14, "usd" );      Money expected = new Money( 26, "usd" );      Money result = m1.add( m2 ); // TWO      assertEquals( expected, result ); // THREE    } } // end of class 

Jill imagines, at point ONE, that there is a Java constructor in the Money class that is written and works, and at point TWO, that a Money.add method is written and works. Notice also at point THREE that there is an assertion that causes the test to simply fail or pass; no human inspection of the specific results is required.

Then, Jill programs just enough of the Money class to make it pass the test testSimpleAdd, writing the constructor to satisfy point ONE, and the add method to satisfy point TWO:

 public class Money { public Money( float value, String currency ) { // body of method ... } public Money add( Money other ) { // body of method ... } } // end of class 

The implementation details are not important, but the process is. Once the code is written, Jill runs the test. If it fails, she debugs till it passes.

Next, Jill is ready for the subtract method. She starts by adding another test to MoneyTest:

 public class MoneyTest extends TestCase { public void testSimpleAdd() { // ... } public void testSimpleSubtract() { // NEW METHOD // body of the new test ... } } // end of class 

Then, she updates Money to make it pass this second test.

Test-first development has some practical consequences:

• Tests actually get written, which yields a host of benefits. This is obvious, but in many projects that do not practice TDD, tests are just not written.

• It is at least a semi-enjoyable way to do testing that makes it more sustainable. Agile methods tend to emphasize practices that developers (eventually) like or at least do not dislike doing. Traditional ("test last") testing is avoided because it is boring or tedious. By writing the tests first, the developer is engaged in thinking through the proper public behavior of the class not yet written. That's interesting and creative. And, she writes the test and then builds something to make it pass. That gives a small feeling of accomplishment.

• To expand a point made in the last bullet, by writing the tests first, the developer is engaged in thinking through the proper public behavior of the class not yet written. That thought process treating the new class as a separate black box with public operations clarifies in the developer's mind the behavior and design of the class before it is programmed. That thinking tends to improve the design and, as a valuable side benefit, a test written.

Finally, note that many IID projects also practice continuous integration. All these tests, growing constantly, become part of the continuous integration test process, re-executed on each build cycle.

continuous integration

Fit or Fitnesse for Acceptance Testing

Ward Cunningham, a key figure behind XP, has created a simple, open-source framework and tool to support acceptance testing: Fit. See fit.c2.com. It has become relatively popular in the agile development community. A related tool, Fitnesse, has been developed by Bob Martin and his team at ObjectMentor, early promoters of XP and agile development. See www.fitnesse.org.