|
||
|
|
|
|
||
Unit testing has been around for a long time, but it gained in popularity with the advent of Extreme Programming (XP). One of the better ideas to emerge from XP is Test-Driven Development (TDD), an extension of unit testing to cover OO design by writing tests from the client code’s perspective.
One of the problems with TDD used without additional design and requirements testing techniques is that it focuses on the smaller aspects of design (not a bad thing in itself), without looking more than a few inches ahead at a time (a very bad thing). TDD is most commonly used with XP, and even XP’s “thought leaders” recommend that you do a small amount of UML modeling (or other form of up-front design) to complement the TDD design process and also write user acceptance tests which, for each user story, should describe a complete vertical slice of the system.
In fact, it’s been widely recognized that TDD needs higher-level design in order to be really effective. Agile Modeling (AM), for example, incorporates this need into a management-oriented process. AM is primarily about promoting “agile teamwork,” doing “just enough design,” and so forth. But it doesn’t go into detail about exactly how to incorporate UML modeling into TDD. So in this chapter and the next, we’ll use a practical example to demonstrate how to model up-front using ICONIX Process and then do the detailed, code-level design using TDD.
In terms of design detail, ICONIX Process gets you from roughly 30,000 feet down to 100 feet. TDD is more about designing at 3 feet above sea level, dodging the waves, so this suggests that the two processes should work well together.
In this chapter, we’ll provide a brief introduction to TDD and walk through a practical example with a travel theme. Then in the next chapter, we’ll hit the Rewind button and show how the same example would have been approached using a combination of TDD and ICONIX Process.[1.]
 |
As there’s some major crossover between TDD and ICONIX Process, you might wonder why we would ever want to combine them on the same project.
Essentially, the processes differ in terms of the philosophy that drives them. TDD is mainly about designing interfaces by writing test code that uses those interfaces: designing by intent. On the other hand, ICONIX Process is about designing interfaces by drawing sequence diagrams that implement specific use case scenarios (i.e., designing the software around the user’s goals): use case–driven design.
In other words, they address different aspects of the thought process that goes into creating a good design. So if we can find a way to combine the two in such a way that duplication of effort is eliminated, then we should end up with a powerful, rigorous design methodology.
|
[1.]You might find, as one of our technical reviewers did, that the vanilla TDD example we present in this chapter, without the benefit of any UML diagrams (“Just the code, please”), is a little bit hard to follow. In fact, we find it a bit hard to follow ourselves. That’s why we propose using TDD in conjunction with ICONIX Process in the next chapter and explain how to do that. We think it’s a lot easier to follow a minimalist set of well-defined modeling steps in advance of TDD.
|
||
|
|
|
|
||