magpiebrain

After some badgering by “Simon”:http://www.brunningonline.net/simon/blog/, I’ve decided to start posting the occasional book review. As a voracious collector (and sometime reader) of books, I feel it is a duty to impart my knowledge on some matters, whilst at the same time whoring myself for a potential paid gig. Either that or to inflate my own sense of self importance, whatever.

Anyway, first up for treatment is Kent Beck’s “Test-Driven Development by Example(Test Driven Development – The Addison-Wesley Signature Series )”:http://www.amazon.co.uk/exec/obidos/ASIN/0321146530/qid=1077822818/sr=1-1/ref=sr_1_11_1/026-5985556-2226861. A rather slim tome in the context of computing books (which tend to value content over quality), it aims to describe the process of Test Driven Development (TDD for TLA fans) by a series of, you guessed it, examples. The first half shows the process being applied to solving a relatively straightforward use case. It succeeds well in managing to introduce the core processes of TDD, but at times the tone of false modesty Kent uses can really annoy me. I know enough of Kent Beck’s work to know that the guy cannot be as mediocre a programmer as he claims in the book, and for him to claim otherwise irks me somewhat.

The other problem the first section has is that in order to simply explain the TDD process, he has to use simple, small steps, which of themselves seem trivial and do not really help show some of the power of TDD. This can often be a problem with trying to describe computing technologies – by the time you’ve got an example simple enough to explain a technology, you’ve removed the need for using the technology in the first place.

Some of the early points are very well made however, this description being the single best argument for test cases I think I’ve ever seen:

In teaching TDD, I see this situation all the time – excellent software engineers spending 5 to 10 minutes reasoning about a question that the computer could answer in 15 seconds. Without the tests you have no choice, you have to reason. With the tests you can decide whether an experiment would answer the question faster. Sometimes you should just ask the computer.

At no stage during the first part is any guidance for setting up a TDD environment given. In addition, whilst JUnit is mentioned as the testing framework several times, no information is forthcoming as to how to run the tests yourself. This can be a bit frustrating to people who want to follow along with the examples from the beginning. This begins to be readdressed in the second part, where by way of a more advanced example, Kent decides to implement a JUnit type system using a TDD approach. In it you get a feel as to how JUnit works, but you still don’t actually know how to download, install and run it.

By choosing an advanced sample such as the implementation of a unit testing framework, Kent is clearly trying to kill two birds with one stone – describe JUnit and give a more advanced TDD example. He does of course make a rod for his own back – he is using the Unit testing framework he is creating (called xUnit) as the test framework itself. I’m sure many computer scientists get a hard-on for this self-referential coding but for my mind it needlessly complicates things.

Perhaps the most notable thing about this middle section of book is the change in programming language. The testing framework he develops is a written in Python. No doubt a boon for Python coders out there, this can’t but help make things a little awkward for those who picked the book up, saw the early sections are written in Java and thought this was the book for them. Likewise Python programmers may have some trouble understanding the Java examples in the initial sections, which would be required in order for them to follow the later Python code.

The real pay dirt for this book can be found in the final section. Here, Kent details a series of test patterns expanding on the early examples which give a fantastic overview of what you should test and how. For me, I found myself skipping much of the early stuff and focusing my attentions on these more complex topics, however I obviously lost out a little – I frequently found myself referring to the earlier chapters to better understand the topics being addressed.

Conclusion

All in all, Test-Driven Development can quite quickly explain to you what TDD is, and what its promises are. It does its best to extol its virtues, but I can’t help thinking that the only way to really be converted to TDD is to use it yourself. The lack of discussion on how to implement a TDD environment for yourself is disappointing, and the brief foray into Python confusing, however all in all this book is well worth a read for any of you interested in the topic.