Accueil > professional > Book review : Test-Driven Development By Example

Book review : Test-Driven Development By Example


I’ve recently read Test-Driven Development By Example, a book from Kent Beck.

I’ve liked the following:

  • description of the TDD cycle : Red – write a little failing test/Green – make the test pass quickly, even if it involves dirty tricks or duplication/Refactor – make the code clean, including hunting for duplicates for example.

    The emphasis on making the test working quickly first was a bit unexpected to me. Indeed, I tend to try to write « clean code » first. It’s not bad in itself, but it happens sometime that I’m not confident with the design. Thus, I feel uneasy. Smaller steps, maybe less clean, would probably help: seeing a green bar is always a good feeling. This leads me to the next point.

  • Kent writes that one of the key point of TDD is about reducing stress : being able to do small steps reduces the stress/fear level, hence fewer errors and better feeling. If the target design is unknown or intimidating, use (very) small steps.

    As pointed before, I wasn’t really aware of this, even if I appreciated the final feeling one has after writing proper unit tests. I’ll try it 🙂

  • The notion of « emerging/organic » design is as well spoken of. It’s the idea that with proper TDD the design will evolve to fit exactly the needs, no more, no less. A kind of perfect match in the end.

    I had already heard of it but it was a nice refresher. Still, it doesn’t fit with our actual practices : we tend to prototype first the design.

    But maybe once I should try starting with a very easy and naive implementation and see where it goes. After a few refactorings, it may end at the same design, or may be even better. Still, I fear it would take more time and I’m unsure about the results.

    On the other hand, as told by Kent, if ever the code has to evolve to become more general, this can be done easily, with the tests providing the required safety net. Then, how many code are designed with a way broader scope that they’ll actually use, leading to verbose and/or a bit inappropriate abstractions ?

    Once again, feedback is welcome, and anyway I’ll test it.

  • TDD helps narrowing and keeping focus. That’s a big reason for the small steps, one thing at a time, so if something behaves in a unexpected way it’s easy to spot early.

    But Kent pushes it further : when doing TDD and using « dirty tricks » to get the green bar, he suggests writing done a list of the stuff left to do. He does so as well for other related ideas popping up. The aim is to keep focus on the current work, coming back later on the todo/improvements noted (which in turn, for sure, can/should be done test first ;)). He suggests using a good old paper list, and simply to strike the work done. As such, progress can be seen easily and is quite satisfactory. Furthermore, the overview is always present and one can easily pick the easiest/smallest stuff to do, for example just before leaving.

    Said this way, it may sound obvious, but the fact is that we tend to lost focus when doing pair programming. Maybe Pomodoro could help us, but this way of doing as well. Again, it’s worth a try !

Still, the book wasn’t only joy to read. The first 80 pages are a TDD example where Kent Beck uses very small steps. Personally, it really went on my nerves. Furthermore, he complains about some lack of features in Java which have been added since (the book is from 2003). It didn’t help neither.

He finishes the book with a small chapters on different patterns, like « red bar », « green bar » , testing, xUnit, design and refactoring. If you have a bit of practices regarding unit testing and if you have knowledge on patterns and refactoring (personally I’ve read books like Refactoring and Head First Design Patterns), there is few to learn there. Only the null pattern did interest me and will be the topic of another post. I wish he has spent more time on testing, like which code coverage to aim for (and why), gui unit testing and common pitfalls.

Maybe some answers lie in the « Testing Object Oriented Systems: Models, Patterns, and Tools » which he presents as « the comprehensive reference on testing ». This time is a 1000 pages book, sounds intriguing 😉 lol


Side note : I often wonder if my reviews aren’t too verbose… I would welcome feedback on the matter !

Étiquettes : ,
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l'aide de votre compte Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )


Connexion à %s

%d blogueurs aiment cette page :