Test Driven: TDD and Acceptance TDD for Java Developers

Lasse Koskela (2007)
Review date: May, 2009

The book is divided into three parts: "A TDD Primer", "Applying TDD to specific technologies", and "Building products with acceptance TDD". The first part's first chapter introduces important TDD concepts, the relation between test-driven and acceptance test-driven development (ATTD), and some useful tools and practices to get you started on the subject.

The second chapter is devoted to a practical example; a template engine is test-driven. We learn how to define test cases and apply the third stage of the TDD cycle: refactoring. The following chapter continues on the topic. Chapter four concludes the first part, wraps everything up by suggesting strategies for testing, explaining the essence of stubs, mocks, and fakes, introducing testing patterns and different assertion types, and touching on legacy code. Phew.

Part two's four chapters deal solely with the technicalities of test-driving different technologies, such as servlets and JSPs, databases (using many different approaches), multi-threaded code , and Swing.

Finally, the third section switches to ATDD. First we learn what ATDD is all about and then how to implement it using the Fit framework. By then only chapters 11 and 12 remain. In the former some further strategies for acceptance testing are proposed, while the author's advice on introducing TDD to the non-blessed are found in the latter.


This is the best book I've read on not only TDD, but also on Java development! The author is really knowledgeable in both these topics, refers to all relevant literature, but above all, manages to write just about enough on every topic he chooses to discuss. I've read this book twice. Once because I pretty much had to. Second time because I wanted to review it properly. First time I read it I finally got what TDD was about, and I picked up a lot of testing techniques. I wasn't ready to explore the plethora of tools suggested throughout the book, and I wasn't ready for ATDD at all. At that time I was amazed by how much better the author was able to describe TDD compared to its own founding father, Kent Beck. Maybe it's not fair to compare a book that introduced something daring and novel ten years ago, with one written quite recently, when the technique has had the chance to spread and mature. But then again, we read literature to learn from it. Compared to "Test-driven development by example", this book explains TDD orders of magnitude better.

Not only is the author good at explaining TDD, ha also manages to squeeze in a lot of testing theory and practice here and there throughout the book. He has managed to pick out the most usable tricks from books like "JUnit recipes" and described them with sufficient detail to get one started. Also, this book is probably the best introduction to EasyMock, although it does hit a wall at a point.

While reading, you notice that the author really knows a lot about software development, and that he's been around. Unintentionally or not, he shows some practices and techniques worth keeping around, like automated database versioning or using Jakarta VFS for file-dependent testing.

Interwoven among all the goodies we also find good examples of and theory on user stories, and many other tools and components of agile methodologies in general.

Unmistakably though, the author's prime contribution to the field is the clarification of the relation between TDD and ATDD: the former makes sure that the code is correct, while the latter ensures that the requirements and their implementation are. It's quite apparent that much thought has been given to formalizing this relation, and as I said earlier, many works in the fields of development and agile practices are quoted to build a solid foundation for this relation.

Ok, so Lasse Koskela knows his Java, his testing, and agile methodologies. What does he not now?

There's not much bad I can say about this book. One thing, that may have a natural explanation in EasyMock's level of maturity at the time of writing, is the author's leniency with the tool. Everything is an expectation and no stubbing is used. On the other hand, the difference between when using stub return values and expectations is emphasized where needed. Regardless of whether I'm right or wrong on this one, this is a ridiculously minor issue.

A real downside may be the lack of structure towards the very end of the book, where the author sort of presents a variety of thoughts on different topics. Simply put, I found the second last chapter difficult to read.

That's pretty much it, so I really urge you to read this book. After having reviewed 27 books and read far many more, I perceive this book as being in its own league.

Who should read this book

Everybody working with Java should read this book. You don't even have to be interested in TDD, as this book contains lots of common programming knowledge.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.