TDD USING HELLO WORLD in Font

Encode Code39 in Font TDD USING HELLO WORLD

The TDD story pretty much starts and ends with unit testing. Given a user story, you create test fixtures and unit test code, and drive the product code from the tests. However, there s a major aspect of testing that is often overlooked by teams who adopt TDD: customer tests (aka acceptance tests). With acceptance tests you re writing tests that cover the requirements; with unit tests you re writing tests that cover the design and the code. Another way to look at it is that acceptance tests make sure you re coding the right thing; unit tests make sure you re coding it right. While unit testing principles are crisp, clear, well understood, and generally easy to grasp, guidance on acceptance testing is rare, vague, and woolly. Acceptance testing frameworks such as Fitnesse provide little more than holding pages for tables of values, while leaving the difficult part plumbing the tests into your code base as an exercise for the reader. In fact, we ve noticed that many TDDers just don t think about acceptance tests. It seems that when TDD was unshackled from XP and allowed to float away over the horizon, a vitally important part of it customer acceptance tests was left behind. This almost blinkered focus on the code isn t surprising, as it tends to be programmers who introduce TDD into organizations.

Now that we ve been through the exhausting exercise of driving the design from the unit tests, let s reflect again on the anemic amount of code that was produced by this herculean effort. Figure 2 10 shows the sum total of the code that we ve tested (on the right, a grand total of 28 lines in LoginManager), and the unit test code that got us there (65 lines in LoginManagerTest, on the left).

Figure 2 10. It took this amount of test code (on the left), not counting refactoring, to produce this amount of product code (on the right). At first glance, this really doesn t appear all that unreasonable. Sixty-five lines of unit test code to produce 25 lines of production code a bit more than 2:1 isn t that unreasonable a price to pay for having a good suite of regression tests. The real issue is how much work it took us to get to those 65 lines of JUnit code.

When you consider that our 65 lines of final test code took somewhere around eight refactorings to develop, you can come up with an approximate level of effort on the order of writing 500 lines of test code to produce 25 lines of product code. So we re looking at an effort multiplier of something on the order of 20 lines of test code for every line of product code. For all this churning of wheels, gnashing of teeth, and object mockery, we ve actually tested only the check password code. All of the other requirements (locking the account after three failed login attempts, username not found in the account master list, etc.) haven t even begun to be addressed. So the TDD version of Login (all requirements) would be a 60- or 70-page chapter. If this seems Too Damn Difficult to you, we think you ll enjoy the next chapter, where we ll show you an easier way.

Summary

In this chapter, we continued our comparison of TDD and DDT by following along with a Hello world! (aka Login) requirement using TDD. It became obvious how the design begins to emerge from the code and the tests. However, you may have noticed that we were spending more time refactoring the test code than the real product code (though this was in large part exaggerated by the simplicity of the example there will be lots more refactoring of product code in a more complex example). The process is also very low-level, we might even say myopic, focusing on individual lines of code from quite an early stage. While one of the primary goals of TDD is improved code quality, it s definitely not a big picture methodology. To gain the picture of your overall system design, especially on larger projects, you would need some other design process in addition to TDD. In the next chapter we restart the Hello world! example and, this time, use it to illustrate how Design-Driven Testing works.