Code Library

If you were to look at how programmers write code on a traditional development team, you would find that they typically select a portion of the program to tackle, write the code, attempt to compile it, fix all the compile errors, walk through the code in a debugger, and then repeat. This process is very different from a test-driven approach, which is also shown in that figure. A programmer doing test-driven development works in very short cycles of identifying and automating a failing test, writing just enough code to pass that test, and then cleaning the code up in any necessary ways before starting again. This cycle is repeated every few minutes, rather than every few hours.

I find test-driven development (TDD) invaluable. One of the biggest reasons is that it ensures that no untested code makes it into the system. If all code must be written in response to a failing test, then if we do nothing else, we at least achieve full code coverage with TDD. You might think a test-right-after approach would achieve the same result. However, I've found that when programmers make a commitment to write their unit tests "right after" they finish implementing a feature, they often do not do so. The pressure to get started programming the next feature can be tremendous. So programmers tend to write tests for only a subset of the new functionality or put testing on a list of things to get to later, and then find that later never comes.

It is appropriate to think of TDD as being as much a design practice as a programming practice. After all, the tests a programmer writes and the order in which they are written guide the design and development of a feature. A programmer doesn't create a list of 50 small unit tests and then randomly choose which to implement first. Instead each test is selected and sequenced so that the uncertainties of the feature are addressed early. In this way, the selection and implementation of tests does indeed drive the development process, resulting in a design that, at least in part, emerges from the needs of the system.

There is some debate about whether TDD leads to more robust or otherwise better designs.1 But there is no doubt that TDD is helpful as a practice that helps programmers think through their designs. A design that is hard to test, for example, may indicate poorly structured code. My recommendation is to do TDD for its testing benefits; any potential design improvements it brings are a bonus.



"I am working on a complex system. I need t o do some architectural work first ."

Yes, on a complex or large system, you probably do. There is nothing to say that TDD as a micro-level practice cannot be effectively combined with a small amount of up-front architectural thinking. The question of how much, if any, architectural thinking to do up front is best considered with achieving that balance in mind.



" Always writing a test first is bound to take longer; I don't have time to waste ."

There is evidence that doing TDD takes about 15% longer than not doing TDD (George and Williams 2003). But there is also evidence that TDD leads to fewer defects. Two studies at Microsoft found that the number of bugs found went down by 2 4% and 3 8% with the use of TDD (Sanchez, Williams, and Maximilien 2007, 6). So, yes, TDD may take longer initially, but the time will come back to the team in the form of reduced bug fixing and maintenance time.



THINGSTO TRY NOW
• Commit to spending at least one full day in the coming week doing test-driven development. If you've never done TDD before, you will likely need to work w i t h another programmer to get the hang of it. Even if your partner doesn't have TDD experience either, it will be easier to learn together.

• Getting comfortable with how to write a failing test before writing the implementation can be difficult. It's a very different way of working. One way to gain a better understanding of it is to try gang programming. Gather four to eight programmers in a conference room equipped with a laptop and projector. Pick a programmer to start coding while everyone else looks at the projected source code. Find one failing test you can write, and then have the programmer write the code that makes the test pass. After 15 minutes or so, pass the laptop to another programmer. Continue writing code and passing the laptop until the task is complete.

• If trying TDD on your full application is too difficult right now, find an ancillary project you can try it on. How about that data conversion program everyone has been putting off? Or the stand-alone program one of the system administrators asked for last month?

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010