Better Software - September 2008 - (Page 26) Whenever we begin to discuss acceptance criteria, it’s safe to say the user story alone is not enough. To establish a shared understanding of a user story, the customer elaborates on the idea behind it by first outlining some acceptance criteria—often in terms of the new behaviors that the system will exhibit once the story is implemented. This is so that the team has a high-level view of the story’s real meaning. Programmers, testers, and the customer exchange examples of specific inputs and outputs that further clarify the scope of the user story. This results in refinements to existing acceptance criteria or additional criteria. During the iteration, programmers and testers work with the customer to draw out the detail required for them to expand outlined acceptance criteria into specific examples in the form of tests. From these tests, programmers infer the underlying rules that must be implemented. During this process, with the help of a variety of testing techniques, testers help to identify exception cases and reduce other example behaviors into equivalent cases. The result is a set of examples, expressed as automated acceptance tests. These tests are run and, since the feature isn’t implemented yet, they fail—as expected. For each of these automated acceptance tests, programmers implement enough of the software for the acceptance test to pass (ideally using TDD with unit tests). Once all the acceptance tests for a story pass, the story is done— almost. Often, exploratory testing is performed around this story to detect cases that the team didn’t anticipate. This feedback can result in more tests for the story or inspire whole new stories. So, that’s a high-altitude image of where you’ll end up. However, becoming proficient in ATDD isn’t just a case of following a process and producing some artifacts. It requires a certain appreciation of the intent, value, and benefits of the practice. Many of us learned by doing, taking the journey to appreciating these factors with little or no guidance along the way. Fortunately, you can take a slightly easier path with the help of these nine key landmarks. ming (XP) emerged and, along with other agile processes, has grown in popularity. Inspired by 1950s programming practices, Kent Beck proposed writing tests before writing the code—something in opposition to the common wisdom of the time. This idea became a core part of XP at two distinct levels—acceptance tests and unit tests. Acceptance or customer tests are written by customers (with appropriate help) to explore and communicate a problem and the behaviors that would solve that problem. These tests are then automated by the cross-functional development team. In contrast, unit tests are written by programmers to explore and shape the software design and its implementation. As the system grows and evolves, thanks to both types of tests being automated, the team has confidence that the software continues to do all the things the team built it to do. Perhaps because many programmers misunderstood TDD, Beck wrote the book Test-Driven Development: By Example [1], which leads you through a series of worked examples in how to drive your design with unit tests. From this point on, TDD became for many a specific reference to the unit-test level of the practice. However, in the section “Mastering TDD,” Beck briefly discusses the issues with TDD as applied to unit tests and how application-level tests solve them. He calls this approach application testdriven development (now more commonly called acceptance test-driven development): The problem with driving development with small-scale tests (I call them “unit tests,” but they don‘t match the accepted definition of unit tests very well) is that you run the risk of implementing what you think users want, but having it turn out not to be what they wanted at all. What if we wrote the tests at the level of the application? Then the users (with help) could write tests themselves for exactly what they wanted the system to do next. Beck goes on to warn of the problems ATDD presents—the problem of writing application-level tests before the applicawww.StickyMinds.com tion exists and the social and technical difficulties of getting users to write these tests. Today, I believe the practice has matured sufficiently that these problems have been solved—more or less. Landmark 2: Specification by Example The word “test” is so prominent that many assume that ATDD (and TDD) are testing practices and ignore another key dimension of ATDD, “specification by example.” To explain specification by example, I need you to forget the phrase acceptance “test-driven development” for a moment. Try to put the word “test” completely out of your mind. In fact, think about something else for a moment. Some random idea, say … Internet radio. Internet radio has come a long way since its inception. Now, services like Pandora.com and last.fm create for each user a personalized radio station that matches that user’s own personal tastes. With last.fm you can provide one example of a song you like, or you can provide a wealth of examples by uploading your own music library to the site. Software analyzes the songs in your library, discovering common aspects of your songs’ “DNA”—genre, tempo, and a number of other characteristics. From this, last.fm creates a user-specific Internet radio station that matches your tastes. As you listen, you give last.fm feedback saying which songs you love and which ones you hate. Your future playlists are refined with each piece of feedback you provide. The feedback itself is, essentially, more examples of songs that do and don’t match your taste. From this, last.fm evolves your playlist, introducing you to more and more new songs in the process, even evolving your own understanding of your musical taste. This is an automated equivalent of specification by example, and this is what we are trying to do with ATDD. Instead of examples of songs, the customer provides examples of software behavior. These examples are represented as acceptance tests. The cross-functional team infers the underlying business rules from these examples, and since the tests are automated, the team can quickly determine when these rules have been implemented. Landmark 1: Understanding the Origin of ATDD In the late 1990s, Extreme Program26 BETTER SOFTWARE SEPTEMBER 2008 http://www.pandora.com http://www.pandora.com http://last.fm http://last.fm http://last.fm http://last.fm http://last.fm http://www.StickyMinds.com
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.