Brian Ray's Blog

Painting is just another way of keeping a diary. --Picasso

Sun, 15 May 2005

Book review of "Unit Test Frameworks"

Unit Test Frameworks November 2004 first edition, by Paul Hamill, is a quick read for any programmer who wishes to get started off on the right foot with Unit Testing. The book emphasizes the methodologies of Test Driven Development (TDD) as a key element in adapting an Extreme Programming (XP) methodology.

Take if from me

I have been reluctant with following the crowd by adapting a Unit Testing framework. I was afraid that building these tests would just complicate things or simply take too much time. My past method of testing was to build tests into debug builds. However, my code is becoming less and less managable now that I am working with larger programs and with larger group's of programmers. I was happy to see the following key points in this book:

  • Test Driven Development is part of the development cycle, so it can not disturb the process
  • Tests may live complete independent of the build code
  • Tests can be organized into Suites, where groups of test can be controlled from "clean" environments as to isolate the testing environment
  • Strong Unit testing frameworks are not only available for the best known cases (ie JUnit), but now in all of the language's I often use: C++ (cppunit), Python (pyunit), and even XML (XMLUnit)

Now that I have read this book, I will never pick it up again. This is a good thing, in this case. I simply wanted to get started on the right foot with unit testing frameworks. Besides the fact it less than 200 pages of content, there is simply not enough detailed information for this book to used as a reference. The book is pricey, however, worth it if your serious about getting started in the right direction.

Errors :

  • The CD was encoded with dos line endings. 'make' distastes these, even though in the book he suggests using G++, with the cppunit sources. Was this a production mistake? It's just plain stupid.
  • The Python callback stack on page 90 indicates running Python under Cygwin. Book examples should show examples only on Native environments.
  • Again with Python, the code examples type setting is off. For some reason, the Identifiers indicated with underscores ( as with system defined names, or class-private name mangling) do not always appear to have spaces between double underscores--they appear as one long underscore. This pops up inconstantly throughout the book--at times, even on the same line.