A Brief Overview of TDD

It’s worth stating up-front one of the main principles behind TDD: despite its emphasis on tests, it isn’t primarily about testing. TDD is actually about designing.

Using TDD, you design code by writing code. While this sounds circular, it means that you write client test code that serves as both an example and a definition of what you want the object code to do. For example, if you were writing a hotel booking system, you would write tests for placing a booking, adding customer details, retrieving the details, and so on. More specifically, you write unit tests that test for the expected results of doing these things. So a unit test for placing a booking would involve placing the booking and then asserting that the booking was correctly placed in the system.

Knowing which tests to write is driven by the user stories (in XP) or the use cases (in ICONIX Process). As you’ll see later in this chapter, the sequence diagrams also play a large part in determining the tests to write.

Micro Testing 

TDD is about designing at a very low level using fine-grained tests. In fact, there’s a trend away from the term “unit testing” toward “micro testing.” “Unit testing” is considered a bit vague, because the test for a large and badly written unit might also be large and badly written. “Micro testing” is more descriptive, in that these tests are meant to be very small.

Using TDD, as mentioned earlier, you’re designing at a few feet above ground level. While this is fine for some projects, most of the time you’ll need an additional design process that operates at a higher level. ICONIX Process is an ideal candidate for this.

There’s some potential crossover in that ICONIX Process takes us to a very low-level design using sequence diagrams (by this stage, the designer/programmer is really thinking in code). We’ll discuss how to splice the two processes at this level of crossover in Chapter 12.

TDD uses the YAGNI^[2.] principle for adding (or, more important, leaving out) features to code at two levels: requirements and design. Requirements-related features are left out on the basis that they’re not needed now, so let’s add them later. In TDD, this process is taken literally. That is, if there isn’t a test to prove that something works, then we don’t write the code; we write the test first. Using this process, tests actually drive the design.^[3.]

To demonstrate this, let’s launch straight into an example using “vanilla” TDD. As you’ll see, the process as applied here works but can be long-winded. In the next chapter, we’ll repeat the example using a more effective mix of up-front design and TDD.

WHY WASN’T TDD USED ON THE MAPPLET PROJECT?

As the mapplet development progressed, one of the issues debated was whether it was necessary or important that the team adopt a test-driven strategy. TDD is a useful technique and a very hot topic these days, and its benefits are enumerated elsewhere in this chapter. Ultimately, it was decided that TDD wasn’t a great fit with the mapplet project because it would involve a substantial amount of effort to introduce this practice into the middle of an ongoing release, and because the team felt that many of the potential problem areas might not be best addressed by unit testing (e.g., visual inspection of a large suite of test maps seemed best suited to testing compatibility across different web browsers and operating systems, and for coverage testing across North America).

One issue the team had was that TDD, despite its name, isn’t primarily about testing. Of course, tests are a major part of it, but TDD is at its heart a design process, rather like ICONIX Process is a design process. Both processes take the design to the code level and provide techniques and best practices for designing clean, focused interfaces with modular, fine-grained classes and methods.

^[2.]YAGNI is an acronym for You Aren’t Gonna Need It. See http://c2.com/cgi/wiki?YouArentGonnaNeedIt.

^[3.]By contrast, in ICONIX Process, use cases drive the design.