Zeger van Hese: Markus, congratulations on your first book, ATDD by Example: A Practical Guide to Acceptance Test-Driven Development, which you published recently. Can you explain what the book is all about? Why should people read it?
Markus Gärtner: Oh, it's not my first book. Back in 2008, I published my diploma thesis on hand-gesture detection. It’s in German, though. Maybe that's why I sold only six copies up until now. Now, you could claim that ATDD by Example is my first book in English. That would be probably right, but I also contributed a chapter on agile testing to How to Reduce the Cost of Software Testing by Matt Heusser and Govind Kulkarni.
So, what is ATDD by Example all about? The book provides an entry-level description of acceptance test-driven development (ATDD). At some point, I figured that the books available on ATDD either describe a tool or focus on the principles. Someone new to ATDD often faces the question of which tool to get started with and does not learn from the principles but rather from clear examples. So, up until now he was in the situation that he had to buy five books focusing on different tools, read them all, and then come up with a decision about which one to use. I wanted to change that.
Now, you can dive into ATDD by Example, work through the two examples using two different tools, and read up on the approach with its principles in the third part of the book. By then, you will have a good feeling for the different approaches of the tools. With Cucumber and FitNesse, I cover two of the most commonly used tools for ATDD around today. I also provide a hint to Robot Framework.
Zeger van Hese: What was your main reason to write ATDD by Example? Why ATDD?
Markus Gärtner: When I first read about ATDD back in 2008, my first thought was “I don't need this.” We had just finished transitioning our functional automated tests from shell scripts, which needed constant attention of ten people, to an approach using FitNesse. We had used test-driven development to develop most of the fixture code, we had continuous integration in place, and we had replaced the previous test suite that had grown over the course of one year—with five people, in a matter of eighteen weeks.