Where does one start when practicing test driven development? With the requirements or with the design? Or, put another way, top-down or bottom-up? When one starts to write a test first, without any code, what does that test represent? Both approaches are practiced in the Agile community, but there is little consensus on which provides more value.
Ryan Kinderman talked to some rails developers and asked them about their approach - do they do Bottom-up or Top-down TDD? He expected everyone to be starting from the top down - i.e. start with the requirements, write tests for those, and then build the system to satisfy those requirements and only those requirements (this is also known as Behavior Driven Development - BDD - do we have enough acronyms yet?!) What he found, to his surprise, is that almost everyone started from the bottom up:
The problem with the bottom-up approach is that it's difficult to really know how a component needs to be used by its clients until the clients are implemented. To consider how the clients will be implemented, the developer must also think about how those clients will be used by their clients. This thought process continues until we reach the summit of our mighty design! Hopefully, when the developer is done pondering, they can write a suite of tests for a component which directly solves the needs of its client components. In my experience, however, this is rarely the case. What really happens is that the lower-level components tend either to do too much, too little, or the right amount in a way that is awkward or complicated to make use of.
As Ryan reports it, it seems that you have to do either or, but not both. On the other hand, others in the field have been writing functional tests (or automated acceptance tests) for a long time, and writing them first. This is sometimes known as story driven development , test driven requirements (TDR), and behavior driven development (BDD). Those who have practiced this, along with test driven development (both bottom-up and top-down) have found that, not only does it improve quality, but it helps build the social culture between customers, developers, and testers.
So, how do you practice TDD? Do you do so in a top-down or bottom-up manner? Does your team practice TDR? Do you take an either/or approach or practice both? And, most importantly, what are your goals for doing so?