ATDD as a Third-Level XP Practice
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the second edition of his book Extreme Programming Explained: Embrace Change, Kent Beck distinguishes between primary and corollary practices in extreme programming. [1] Among the primary practices, Beck lists pair programming, the informative workspace, and a 10-minute build. Among the corollary practices, he mentions incremental deployment, a single codebase, daily deployments, and so on. Beck explains that he learned between the first and second editions of Extreme Programming Explained that teams won't be able to implement the corollary practices until they have some of the primary practices in place. For example, without a 10-minute build, daily deployment becomes impossible. Without pair programming, continuous integration, and test-first programming, practices such as shared code, code and tests, and a single codebase become a nightmare.
While I was writing and implementing the acceptance test-driven development (ATDD) examples for ATDD by Example: A Practical Guide to Acceptance Test-Driven Development, [2] I assumed that teams can work with automated acceptance tests on multiple levels. I don't claim that I invented any of these tests. In fact, I recently read a 2005 German book, Testgetriebene Entwicklung mit JUnit und FIT: Wie Software änderbar bleibt (Test-Driven Development with JUnit and FIT: How Software Stays Changeable), [3] in which author Frank Westphal combined then-current ideas about mock objects and outside-in development. Those ideas led to Steve Freeman and Nat Pryce's 2009 book Growing Object-Oriented Software, Guided by Tests. [4] In another 2005 book, Fit for Developing Software: Framework for Integrated Tests, [5] Rick Mugridge and Ward Cunningham wrote about ATDD and collaboration across all the roles in a project. So, in fact, the ATDD approach is quite old.
Having seen how all these different people apply test-driven development in one way or another, it occurred to me that a similarity exists between the application of ATDD and Kent Beck's primary and corollary XP practices. Teams can gain the biggest benefits by starting with the involvement of a real customer. This refers back to specification workshops, where ideally a customer talks with us about upcoming features for our products. The next step for most teams lies in automating the examples that they and their customer identified in the workshops. At first, automation might follow this process; however, if the team improves its process continually, over time they should be able to develop tests and functionality in parallel. I've rarely seen a working outside-in development approach put into practice. However, if the team achieves collaboration across all roles involved, they can develop the software based on the high-level examples from their customers. Let's take a closer look at these three different parts of the process—specification workshops, automated functional tests, and outside-in development—and relate them to the primary and corollary practices of XP.
Specification Workshops
Kent Beck lists real-customer involvement as part of the corollary practices. Yet teams that are new to Agile processes often struggle with customer collaboration. Without a whole team sitting together in its informative workspace, getting real customer buy-in becomes a difficult duty. I work with teams from their first day to get in touch with the business side. One of the main advantages of this approach becomes apparent when the team delivers working, useful software to the customer for the first time. With every new on-time delivery, a trusted relationship is fostered. I think this practice is crucial in software development.
XP describes the role of the onsite customer. The idea is that a customer is in the same room with the team, working closely with the team on a daily basis. Scrum talks about the role of the ProductOwner in this regard; the ProductOwner should be available to the team at least 50% of the time. With such direct collaboration, teams avoid playing the children's game of "telephone," and they can implement software that really enlightens its users.
Specification workshops should involve the whole development team, or at least every special role should be part of it. At minimum, the "three amigos"—the ProductOwner, a programmer, and a tester—should attend. [6] On a basic level, you can hold specification workshops after forming your whole team. Specification workshops then become a corollary practice to the whole team practice from XP.
In the light of real-customer involvement, however, specification workshops might also be one step further away. Without real-customer involvement, it will be hard to derive and trawl the requirements for the upcoming features. While the ProductOwner or onsite customer can help the team as a customer proxy, the tacit knowledge from real users will be distorted—like messages becoming lost in translation among kids in the telephone game. On the other hand, if the team manages to involve a real customer, a real user, or a real stakeholder of their product into their specification workshops, then the workshops as a practice become a corollary to XP's real-customer involvement. I recommend at least starting to work on this relationship early with real users.
So specification workshops might be both first-level and second-level practices, in relationship to the workshops Beck mentions in his second edition of Extreme Programming Explained. But there is certainly more to ATDD than just specification workshops. Let's consider another aspect.