agile testdriven

Last modified: October 18th, 2013

 

One key benefit of agile software development is the ability to make changes to the code quickly and easily. As the team embraces changing requirements as a part of a living, breathing system, they need to know that their changes will not cause a domino effect of broken code. Ideally, the design of the system will be so simple and well isolated that any possible effects of a change will be readily apparent. In the real world, this is not always the case, especially when working with legacy systems. In this case, something must be implemented to ensure that if a change affects other areas of the system, there will be an immediate red-flag, rather than having to chase down the issues later.

After experimenting with different ways to enable this flexibility, agile teams hit upon the practice of Test Driven Development, which involves producing automated unit tests for production code before you write that production code. Instead of writing tests afterward (or, more typically, never writing those tests), you always begin with a unit test. For every small chunk of functionality in production code, you first build and run a small, focused test that specifies and validates what the code will do. This test might not even compile, at first, because all of the classes and methods it requires may not yet exist. Nevertheless, it functions as an executable specification. You then get it to compile with minimal production code, so that you can run it and watch it fail. You then produce exactly as much code as will enable that test to pass. Sometimes you expect it to fail, and it passes, which is also useful information. 

This technique feels odd, at first, to quite a few programmers who try it. It's a bit like rock climbers inching up a rock wall, placing anchors in the wall as they go. Why go to all this trouble? Surely it slows you down considerably. The answer is that it only makes sense if you end up relying heavily and repeatedly on those anchors (unit tests) later. Those who practice Test Driven Development regularly claim that the benefits of those unit tests more than pay back the effort required to write them.

For Test-First work, you will typically use one of the xUnit family of automated unit test frameworks (JUnit for Java, NUnit for C#, etc). These frameworks make it quite straightforward to create, run, organize, and manage large suites of unit tests. Test Driven Development has grown to be such a useful tool that it is well integrated into most of the major IDEs, including Visual Studio and Eclipse.

Test Driven Development: By Example
(Kent Beck)
Working Effectively with Legacy Code (Michael Feathers)
xUnit Test Patterns: Refactoring Test Code (Gerard Meszaros)
Test Driven Development (Wikipedia)
Introduction to TDD (Scott Wambler)
The Three Rules of TDD (UncleBob)