Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL

Preface > Why Another Book on ATDD? - Pg. xvi

xvi Preface From my perspective, any of these names comes with a drawback. Acceptance Test-Driven Development creates the notion that we are finished with the iteration once the acceptance tests pass. This is not true, because with any selection of tests, the coverage is incomplete. There are gaps in the net of tests. In the testing world, this is well known as the impossibility to test everything. Instead we know exactly we are not finished when an acceptance test fails---as Michael Bolton put it. Despite arguing for one name or another, I decided to put a selection of possible alternatives here and have the readers decide which fits best their need. In the end it does not matter to me what you call it, as long as it's working for you. The world of software development is full of misleading terms and probably will stay so for some more years. Software engineering, test automation, test-driven development are all misleading in one way or another. As with any abstraction, don't confuse the name for the thing. The expert knows the limitations of the name of the approach. But why have there been different names for a similar approach? The practices you use may very well differ. Having visited and consulted multiple teams in multiple companies on ATDD, they all have one thing in common: Each team is different from the others. While one practice might work for your team in your current company, it might fail dramatically in another. Have you ever wondered about the answer ``it depends" from a consultant? This is the source of it. For his book Specification by Example [Adz11], Gojko Adzic interviewed more than fifty teams that apply ATDD in one form or another. What he found is a variety of practices accompanying the ATDD approach. All of the teams that apply ATDD successfully start with a basic approach, then revisit it after some time, and adapt some changes in order to fit their particular context. Starting with a lightweight process and adapting new things as you find problems is a very agile way of implementing any approach. As you apply ATDD, keep in mind that your first set of practices is unlikely to solve all your problems. Over time you will adapt the solution process as you gain more and more experience. Why Another Book on ATDD? While Gojko describes many patterns of successful ATDD implementations, I found there is a major gap in the books on ATDD up until now. There is a considerable difference between advanced adopters of a skill or approach and entry-level demands for the same skill or approach. When going through the literature on ATDD, I found several books that explain ATDD on an advanced level by referring to principles. For an advanced learner, it is easy to apply principles in their particular context. However, this does