Test-Driven Development: By Example
2003, xix, 220 p., Softcover
What could a book titled Test-Driven Development be about? Right, it’s about Test-Driven Development, TDD for short. TDD is a testing method and a design method. Write tests first and let them “drive the design”. The book has several flaws and from today’s perspective, I think it has mostly historical relevance.
Content and Structure
The subtitle of Test-Driven Development is not for nothing By Example. Two of the book’s three parts contain each an example about how to use TDD in practice. The third one is a collection of various “tricks, […] design patterns, and […] refactorings” (p. 121) relevant in Beck’s opinion for TDD.
The first part The Money Example demonstrates by means of a relatively simple Java example the usage of TDD. The problem at hand is adding two amounts of money in different currencies, hence a “Money Example”.
The second part The xUnit Example proves the usage of TDD in the context of a more challenging problem: porting the JUnit-Library to the programming language Python in a TDD manner. To put it in Becks words: “we are writing test cases to test a framework that we will be using to write the test cases” (p. 91).
The third part Patterns for Test-Driven Development contains useful “patterns” in the context of TDD. Some examples (one more or less randomly chosen “pattern” from each chapter containing patterns):
- tests should be isolated from each other (chapter 25: Test-Driven Development Patterns);
- in order to understand how an API works, an option is to write so called “learning tests” in order to understand the APIs behavior (chapter 26: Red Bar Patterns);
- objects which are not directly tested, should be mocked (chapter 27: Testing Patterns);
- when there is an “obvious implementation” to a problem it should be implemented without further ado, i.e. without small steps in between (chapter 28: Green Bar Patterns);
- tests should be grouped in suites and run together, severeal suits should accordingly be aggregated to a single one (chapter 29: xUnit Patterns);
- chapter 30 Design Patterns describes shortly various classical design patterns like the template method pattern;
- chapter 31 Refactoring contains some refactorings like „move method“ described in Martin Fowlers eponymous book.
In the book’s last chapter Mastering TDD Beck provides some further advice on TDD and discusses relationships with other techniques or methodologies and possible limitations.
Test-Driven Development is a short book written in a rather loose style about what TDD is and how it can be used in practice. Meanwhile almost twenty years have passed since its publication. TDD might be considered even older since Beck does not consider himself as its “inventor” but merely as the “rediscoverer” of TDD. The book’s „age“ has of course to be taken into account when reviewing it. Nonetheless, it suffers from several shortcomings:
- The examples are hardly appropriate. The one described in the first part is extremely long and rather trivial. The problem proposed in the second part is an interesting but in no way a representative one. Judging by the example in the second part and some of the content of the third part, the book targets more experienced software developers, which makes the first example appear even more inappropriate.
- It remains ultimately unclear how larger software can be “test-driven”, although the author claims this is possible (see for example p. 195 where Beck claims that TDD can „lead to frameworks“ or p. 198 where TDD is described as being fit for „enormous systems“). The author acknowledges the fact that TDD is in no way scientifically validated (p. 202), instead he states that the „anecdotal evidence is overwhelming“ (p. 203). Anecdotal evidence can be regarded as an important first step, but more is needed before it can be claimed that a method is fit for purpose.
- The loose writing style is not uncharacteristic for Beck’s writings, I definitly prefer a more sober style but this can be considered mostly as a matter of taste.
- The book does not describe its context, it rather assumes it. When starting the book, I had the feeling as if it were already more or less clear what TDD is as if TDD were something which was „in the air“ at that time – which it very well might have been. (In a book about testing I would also expect some theory about testing.)
- I suppose some topics like running tests in suits are so common-sense today that nobody would bother to describe them as a “pattern” in a book about testing, but this is where it has to be remembered when the book was written. Several such “patterns” are described in the third part.
How would I have perceived the book back then? It’s impossible to know, but I can speculate. JUnit was still fairly new in 2002 when the book was published (copyright year is 2003), Java itself wasn’t much older either, Extreme Programming was even newer – there was a lot of optimism in the air back then (this is also part of the assumed context). The book fits well in that period and it captures a little bit that period’s zeitgeist. It’s possible – even probable – that I might have perceived the books as being “fresher” because of this reason, but it’s basic flaws would have bothered me back then too. As of today, I think Test-Driven Development. By Example has mostly historical relevance.
Information about Kent Beck can be found on the separate book author page (page is in German).
Folgende Rezensionen könnten Sie ebenfalls interessieren:
- Kent Beck – Extreme Programming: die revolutionäre Methode für Softwareentwicklung in kleinen Teams
- Michael Tamm – JUnit-Profiwissen. Effizientes Arbeiten mit der Standardbibliothek für automatisierte Tests in Java.
- Martin Fowler – Refactoring: Wie Sie das Design bestehender Software verbessern
- Robert C. Martin – Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code
- Michael Feathers – Effektives Arbeiten mit Legacy Code: Refactoring und Testen bestehender Software