Better Software - November 2007 - (Page 36)

elcome to TDD Test-driven development (TDD) is a term used for a collection of agile development techniques. While “testing” is part of its name and it includes tests and fits in that part of the lifecycle usually reserved for unit testing activity, TDD pundits universally insist that it is not a testing technique, but rather a technique that helps to focus one’s design thinking. The idea is that you write your tests first and your code second. In this article, we explore some of TDD’s subtle pitfalls that we have discovered from experience, our consultancy on real projects (all of the conjectured problems are things we have actually seen in practice), and a bit of that rare commodity called common sense. A Conjectural and Metaphorical History of TDD We want to start this story with a conjecture. It is not intended to represent truth but, in a popular agile tradition, is a foundation for metaphor and allegory to help make some of the TDD problems more memorable. If elements of the story happen to be true, so much the better. Once upon a time, software development was doing more or less OK when it employed use cases to help bridge the connection between developers and endusers. Healthy organizations developed use cases for their intended audiences— including the coders and testers—all the while keeping the use cases readable for the client. Use cases were intended to avoid over-constraining the solution; they were written in terms of pre- and post-conditions, rather than attempting to convey the intent in a code-centric, ifthen-else style. Alistair Cockburn created an informal instrument called user stories to present an example of a use-case enactment. User stories have a true element of “story” to them and were never intended to survive into the project (see the StickyNotes for more information). However, some organizations employed use cases in the worst possible 36 way, specifying details of program-task sequencing instead of sticking to requirements. For example, there might be a business rule stating that one cannot go into a normal Danish train ticket office and place an order for train travel to Sweden and another rule stating that such tickets can still be printed at main Danish ticket offices. The organization would create use cases for purchasing a Danish ticket and printing it at a Danish ticket kiosk, as well as use cases for exotic extensions whereby one calls the Swedish train company and books a ticket by phone and has it printed at a main Danish ticket office. The developers would turn this into a nested, if-then-else hell, rather than first writing the normal sequence and delineating special cases with extensions and business rules. On the other hand, the Extreme Programming (XP) people, wanting to take things to the opposite extreme, turned the knob up to 10 on simplicity: Use cases gave way to Alistair’s user stories—about 5 on the knob—which were further pared down to feature lists. Wanting to capture the market interest of those who formerly had employed use cases, the XP people took Alistair’s name for his agile articulation of a user interaction with the system. The XP feature lists came to be named user stories, and Alistair went in search of another name for his concept. As Robert Martin put it, an XP user story was nothing more than “a mnemonic token of an ongoing conversation about a requirement” (see the StickyNotes for a reference). Meanwhile, Alistair’s concept—renamed “usage narrative”—provided a good starting point for exploring the business space, a stepping stone to more detailed use cases with enough information to support actual development. This concept would thrive in successful organizations as an application of the pattern “Narrative and Generic” (see the StickyNotes for more information). At about the same time, the Smalltalk community found that it was weak on testing. This problem was due in part to the fact that most Smalltalk projects were too small to justify hiring a tester, so the only people left to do testing were developers, who usually lacked professional testing skills. This gave birth to a testing methodology using a testing framework www.StickyMinds.com (see the StickyNotes for a link). As the XP world moved away from Smalltalk toward Java, a tool called JUnit was spawned. However, as time went on, the community found that unit testing didn’t find many bugs—many still leaked through to the customer. System testing never was a big part of the culture, and it became difficult to sell testing to the XP constituency—testing was usually left to team members who were viewed as second-class citizens or was outsourced and, as such, was never a revenue-generating business. The testing framework and JUnit weren’t garnering consulting gigs any more. It didn’t help that testing wasn’t “fun” and that “fun” is a core value of XP. As Jimmy Nilsson says, the TDD advocates motivate its value by telling us that TDD is fun— not so much for its value, but for novelty for its own sake (see the StickyNotes for a link). Turning the simplicity knob up to 10, the XP people also chose to simplify the complexity of up-front design. In XP Installed, Ron Jeffries writes: Get a few people together and spend a few minutes sketching out the design. Ten minutes is ideal—half an hour should be the most time you spend to do this. After that, the best thing to do is to let the code participate in the design session—move to the machine and start typing in code. Architecture was replaced in concept by the smaller and more abstract notion of “metaphor,” and even metaphor was limited to a bit of up-front work and the occasional reference during development as needed. The approach left much to be desired. Programmers found they needed a written record of some of the finer details of scenarios—much finer than what a user story conveyed. Programmers needed these not only to help them understand requirements but also to write their tests. At the same time, while XP criticized heavyweight up-front design, it offered no real alternative except to “let the code do the talking.” One brilliant idea would address all of these problems: Recast the JUnit test scripting as a design activity rather than 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.