Book Review: Test Driven Development By Example (Kent Beck)

GitHub

I have coded the examples and both are available in GitHub.  Money  and xUnit 

Delayed...

I am recalling this after a few weeks finishing the book (I should've done this immediately so my memory is hazy, but the code examples should attest to the fact I have read it, if my descriptions of the text are a little ambiguous) 

I have read this book on a number of occasions previously, in reference form and once all the way through,  but hadn't worked through the examples in  a code editor.  I think, for real value, you have to  code the examples, after a while it does feel like you are actually pairing, like others who have reviewed this though, I think the humour leaves a bit to be desired but its not too distracting!

I have been TDDing for a while but this was a good refresher and reminded me of the maxims and techniques "fake it till you make it",  "obvious implementation" and "triangulation". There are also some nice "red" and "green" patterns described later and I refactored to "pluggable selector "and a "command" pattern in some code in production just a week later (it was a nice refactoring and made some abstractions that were needed,  nice and crisp)

Money

The money example was harder for me to get to grips with (contrary to Kent saying that the xUnit example is harder) because I found it more abstract and contrived .  Its coded in Java and is very easy to follow from a syntax point of view, there are few gaps from Kent in guiding readers  when building this example out.  

When having money work with expressions, the abstractions become a little unclear to me and  I don't know if I would ever get to the design presented - and - if I am honest - in my first pass I didn't fully understand it all.  It seems that I am not the only person to have found some of the abstractions confusing, this guy did too.

The xUnit example, however,  I really enjoyed.  

xUnit

I  stumbled on  the driver for the xUnit example and how it  ended up the way it did when finding this from Kent. The Junit cooks tour,  the arrangement of all the classes and the patterns used for JUnit are clearly the basis for the xUnit example, this adds extra gravitas and realism to the example because JUnit is an important bit of software!

The exercise and the steps to help drive out the xUnit framework are still relatively small but they get a bit bigger towards the end and Kent leaves a few more open ended bits to fill in yourself.

One thing which is a bit "chicken and eggy" with getting the test framework going  (Kent does refer to an "Inception" like approach at the start of the example), and can be overcome by bootstrapping in itself, I suppose, is that Kent uses Python in his example,  which has a built in "Assert" method, this is convenient, if using Python, however it is not possible in C# (without building out Assert or using another test framework, which has Assert, to build it out) 

This means that you can start using Assert (if writing in Python) without creating Assert, this did leave me wondering which order to build Assert out (and this isn't covered in the book). I.e. "should I build Assert first" or "should I bootstrap the test framework and then build out Assert with the test framework" or even " build out the test framework with another test framework". You might think I've lost the plot here , but - if you  read the chapter - you will know what I mean.  The rambling above aside, I actually built out Assert last and relied upon "Debug.WriteLine" and visual checks to ensure tests passed.  I  developed and started to back fill Assert in the tests I have uploaded but I was getting a bit confused about how to test it.  Take a look, hopefully you can see what I mean. 

I really did have a smile on my face when you are taken through creating the test framework with a test (WasRun - terrible name :)) which is then tested by the test framework you just created. 
Basically building out "template method" in small steps ensuring small parts of what is used to create a typical test fixture "SetUp", "Run", "Teardown"  and eventually a TestSuite, are built up over the example (and thus you are exposed to Template, Command, Pluggable Selector and Composite patterns - all very interesting) .  This intimate insight allowed me to imagine  how a TestRunner would evolve and enumerate test cases (this isn't actually done in the book or in my coded example) The example could obviously be taken on and used as a basis for your own test framework.

In Summary

Its a good book and the key points about writing a failing test and building out the functionality to build it along with going in smaller and bigger steps when you need to, are reiterated many times.  The introduction of using a checklist to remind yourself of things you need to give attention to as you reveal the design, as you go, is a good tip too, I've used this on lots of occasions in work (and my colleagues have to) but it tends to fizzle out (clever people - I have read - are usually pretty regimented and consistent  in at least some of the stuff they do - I am neither - ask someone who knows me )

Having read Sandi Metz's book- 99 bottles of OOP, I noticed that she has  even better commentary about cutting over when refactoring (by way of comparison - neither book is about refactoring per-se) so there are obviously other books (Fowler's Refactoring chief among them) that can help with specific aspects of the TDD cycle (red-green-refactor) but this is a good overall book about approaching TDD. 



Comments

Popular posts from this blog

SSDT March 2014 Static Code Analysis Extensibility

Testing, Testing, 1.2.3.4.5.6..ad infinitum