A paper on TDD for web apps is online at the Agile Alliance site. Edward Hieatt and Robert Mee have written a nice experience report on how the used TDD within their world at Evant. There were just lots of great insights in this article!!
First, how did they get started with TDD? They sat down as a group and groped throught the process of writing the first tests together. Now I am sure one could get mentoring and training, but I wonder if anything is better than fighting through it on your own. What a great model for kicking off the team effort!
Second, TDD allowed them to practice what Ron Jeffries calls emerging design leading to emerging architecture. It allowed them to start with EJBs, then move off of them with minimal impact and high confidence. It allowed them to move into JSPs and then out of them with minimal impact. It forced them to confront some of the harder TDD problems, like how do we test javascript effectively. It forced them to explore separation of concerns between servers and clients from the beginning. It forced them to create an acceptance testing framework that also served as an EAI integration framework when that was required.
Third, it allowed them to minimize documentation on the development side by forcing them to document tests well enough to serve as documentation.
Let's look at those emergent architecture points just a bit more. First what is emergent architecture? Eric Sheid has a good site for emergent architecture linkage in the context of IA. But from my standpoint, emergent architecture is the result of TDD plus the "You aren't gonna need it," (YAGNI) principle plus the "Do the simplest thing that could possibly work" (DTSTTCPW) principle.
Let's get rid of the problems that probably shouldn't have been problems had YAGNI and DTSTTCPW been in force from the beginning. It is likely that the EJB problem would not of occurred because EJBs violate both principles.
For every other point, one can argue that a well executed predictive system development process (BDUF) could have prevented the problem by "considering it from the beginning". The underlying assumption in that statement is that the engineering involved in refactoring is greater than the engineering involved in up front infrastructure work. But that equation only works if the emergent architecture is ignoring critical customer requirements. In any case where the stories have been identified and prioritized, the critical requirements will emerge and be dealt with. And the added benefit of the constant refactoring is the team acquires the confidence to do serious refactoring in ways that are efficient and effective.
Commitment to emergent architecture means taking away the blame game (why didn't the customer, the requirements analyst, the development team, the management, the testers, the vendors, etc. foresee this problem and do something about it). Commitment to emergent architecture does not mean ignoring requirements, does not mean not thinking about design choices, does not mean making poor design choices. The commitment simply means that we will make the best choices we can based on what we know "right now". It means that we trust the participants to make needed changes as they are needed with high confidence that the result is both operationally equivalent and runs.
10:41:32 AM 
|
