Better Software - November 2007 - (Page 39)

of dialogue with the client. As you write use cases, you will discover conflicts—even at the business level. A classic example from telephony is to develop the call-waiting feature first and the call-forwarding feature second. If you develop either one independently, you miss facing the decision of what to do when someone attempts to place a call to a client who is on a call, has call forwarding enabled, and also subscribes to call waiting. If you capture this scenario information in JUnit or Cactus, one user story at a time, you risk major rework at some point, not only of the code but also of the tests. It is a design issue that affects the most fundamental structures of the code—structures you can’t refactor into the code if you miss them the first time around. Even worse, and perhaps more likely, is that your end-user won’t discover requirements bugs until deployment—bugs that could have been caught by clarifying scenarios before writing a single line of code. You can improve the stability of both your code and your tests by employing use cases as a kind of “fixed point” of development. The developers accept our suggestion, and they go back and redo the original reservation user story, including rewriting the test (it fails), updating the code (the test still fails), and going into several iterations with test and code until both fit (the test passes) and they seem to fit the modified understanding of the functionality—which was never captured in a test before the decisions were reduced to code. The code ends up a mess because of these missed assumptions. No problem: The developers will refactor their way out of it. However, the refactoring browser isn’t much help because most of the restructuring at this point is taking place across class hierarchies. Well, we still tell the boss it’s refactoring, and after a small, one-week delay (on a two-week sprint), we’re in good shape. In the meantime, our competitor has shipped another release. Lack of good architectural delineation from up-front design and use cases can lead to major restructuring as the team learns, a bit at a time, what the system struc- ture is supposed to look like. Refactoring often isn’t an option, because the changes sometimes go beyond what good refactoring can achieve and take us into the arbitrarily general world of hacking and re-design. The solution: • Do just enough up-front, lightweight architecture to support the structuring of the development organization, map onto the physical system architecture, and do a good job of supporting usability. • Consider that the structure of the code must fit the structure of the human/computer interface, so the development team takes cues from usability people when formulating the system-object structure. Team members check out recent empirical findings by Maria Siniaalto and Pekka Abrahamsson (see the StickyNotes for a reference) and are relieved to find that they have done exactly the right thing. Our developers found the same thing that Maria and Pekka found—the use of TDD makes key architectural indicators worse. This runs counter to common claims that TDD leads to more cohesive systems. Recent research has also found that TDD can cause some parts of the code to deteriorate (see the StickyNotes for a reference). Though local complexity metrics are a bit better with TDD than without, the dependency management metrics are clearly worse. TDD is an architectural nightmare. But, architecture in hand, our adventuresome developers are back on track. It’s finally time to demo the system to the customer. The customer sits down and enters an illegal sequence of keys. The customer turns out to be a good tester, because the program crashes. The sequence entered by the customer-as-user puts the system into a state that had been unforeseen by the developers in fleshing out the user stories. It was certainly not a scenario the customer would have thought up beforehand; exhaustively enumerating error cases is, well, exhausting. The problem was in the interaction between two objects rather than in any single object. www.StickyMinds.com Testing individual classes leads to no guarantees about the soundness of the objects of that class interacting with the objects of another, independently tested class—or even between cooperating objects of that single class. This problem, too, can be redressed: • Write tests at the level of some meaningful business concept. The tests should be something traceable to customer desires and possible system-user interactions, not to something inside the system. • Tests should be written directly from customer input rather than from something created by the developer in isolation. Too many tests are created from the programmer’s internal understanding of the program, rather than from an understanding of business needs— which often are emergent properties resulting from the interaction of several classes. There is rarely a direct mapping from the systems thinking of solving user/business problems to the structure of a simple, individual class. Only in those systems where such mapping is straightforward do simple techniques work. Few systems of interesting commercial value are so simple. The team takes our advice and redoes everything, so the tests now reflect concerns of business value. The team has built a collection of individually robust objects that all pass their tests. A few of them have mocks, but the team has been smart to build higher-level constructs on lower-level ones. True to TDD, they do this one test at a time, each one driving some functionality of some object, which in turn may depend on other objects below it. So the team has struggled to get the first iteration to market. The industry knows that first iterations are easy: Almost anything works on a greenfield project undertaken by a single, small team. But agile talks about change, and changes happen. Agile doesn’t talk about bugs, but bugs happen. What are the repercussions of change and bugs on a TDD system? How about the propaga39 NOVEMBER 2007 BETTER SOFTWARE http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2007

Better Software - November 2007 Contents MarkYour Calendar Technically Speaking What’s Happening @StickyMinds.com Code Craft Test Connection Management Chronicles The Measure of a Management System Behind the Scenes A Story About User Stories and Test-Driven Development Product Announcements The Last Word Ad Index

Better Software - November 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.