What do you do first? The requirements or the design?
infoq posted:
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.
It's really not a surprise, once we think of it. But doesn't it somehow subvert the TDD pure practice?
No comments:
Post a Comment