Better Software - November 2007 - (Page 38)

as a testing activity. This made the central concepts of XP more appealing to programmers than any testing regimen would—because design is fun. Development would necessarily start with JUnit: You had to write a test before writing any code. At the same time it appeased the collective conscience of the community by having a testing technique (now to publicly be called a design technique) in its vocabulary, addressing the weakness uncovered in the Smalltalk community in 1994. XP could now point to TDD as its design methodology—something close to the programmer and far from the heavyweight architects and second-class testers. It made sure that TDD would be portrayed that way through repeated insistence that TDD is not a testing method but a design method. It was even touted as an analysis method whereby we “put the analysis efforts into the tests” (see the StickyNotes for a reference). Yet it was still offered as the safety net that allowed programmers to move boldly forward by ensuring they didn’t step outside the boundaries of stipulated behavior— which means to employ the scripts as tests. The XP approach appears to balance all of the forces—the need to engage the development community as well as the user community, the need to capture lowlevel scenario information, a sustained market for JUnit, and the need to avoid heavyweight techniques such as up-front architecture. But in solving what were supposedly serious problems, is it possible that these “solutions” actually made trouble? You’ve heard the tutorials; you’ve read the books. In our work together, we three authors have seen where the rubber meets the road and have had the opportunity to follow TDD projects over the course of several months—sometimes years—to assess the long-term damage. Let’s follow our metaphorical project around for a while to elucidate possible TDD pitfalls. who has been working in the same area. The two decide to code a certain user story that day. They discuss how the feature should work and discover they have to write two test cases to cover the user story. They write the tests and, true to the TDD methodology, execute them before writing any code to ensure that they fail. They do fail. It is simple and takes about ten minutes—well within a single Ron Jeffries design sprint. The same pair then code up the class. This takes a bit more work—about an hour of iterating the code to pass the tests. Along the way the pair creates two more tests. Predictably, when they are finished, all four tests pass. Here we find our first risk: If the same people write both the tests and the code from the same base understanding or formalism, the chances of creating a self-fulfilling prophecy are high. Here’s the problem: Most software bugs reflect assumptions of the coder. A single programmer has a single set of assumptions, and any traps within those assumptions will not be caught if the same programmer writes the code and the test. This can happen even in simple cases, such as creating a linked list. Our programmers don’t know that their train reservation library will be used in a multithreaded system, with the potential for one thread to traverse a list of scheduling options while another application updates routing information in real time. Eventually, this error will cause a member of the National Assembly to miss a train into the city for an important vote on a conflict with Sweden, which will turn the political tide and ultimately lead to World War III. Two programmers who are pairing can mislead each other into assumptions that would be avoided if the pair were separated. To put it differently, pair design and pair programming lead to pair assumptions—a variation on groupthink (see the StickyNotes for a reference). To remedy this pitfall, use the following techniques: • Develop the test from a set of formalisms different from those used for the design. For example, derive www.StickyMinds.com the design from a good use-case description while deriving the test from business rules or invariants. • Have a different person develop the tests from the person who develops the code. You can use either or both of these techniques together. The team develops a bit further and considers another set of user stories. The pair can see that these user stories have detailed cases that interfere with assumptions made in a previous test case. In particular, they find that a previous test case presumed that a given reservation could be found in the database using a ticket kiosk ID or main office ID as a primary key. The primary key captures the site making the original reservation of any ticket issued in Denmark. However, the new user story says that the end-user can reserve a ticket to Sweden by calling the Swedish train company and that the ticket will be issued at a main Danish train company location—even though it is impossible to make a booking to Sweden at a main Danish train office. User stories, processed and elaborated in isolation during coding, fail to capture the interesting extensions that come about from feature combinations or exceptional conditions. There is nothing to encourage the coder to think about these during TDD; because many of these extensions involve multiple objects, such considerations are likely never to arise at the class level. To fix this, we again go back to the future: • Develop and iterate use cases up front, giving good coverage to all of the cases relevant to your next customer deliverable and capturing other pre- and post-conditions that you know. • Give particular attention to usecase extensions and exceptions so you understand boundary cases. While the code may ultimately be the design, it is totally inappropriate as a tool to support the social activities of design. Use cases, on the other hand, support a culture A Journey with Some Metaphorical Developers So the XP programmer comes to work one morning, finds a list of user stories, and pairs up with a colleague 38 BETTER SOFTWARE NOVEMBER 2007 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.