ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1949 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Title:
Test-Driven Development
Author:
Kent Beck
ISBN:
0-321-14653-0
Publisher:
Addison-Wesley
Pages:
220pp
Price:
£22-99
Reviewer:
Francis Glassborow
Subject:
testing
Appeared in:
15-1
The author's credentials for writing on this subject should be well known to you. Just in case you have missed it, he is one of the principal architects of the Extreme Programming member of the Agile Programming Alliance. Once you realise this you may also, correctly, conclude that the code will not be C++. It maybe that I have missed something while reading this book, but I do not think the author actually tells us what language his sample code is written in. I am pretty certain that the code in Part 1 has been extracted from Java. I say extracted because the code is all implementation level detail.

When we move on to part 2 the author does tell his readers that he is now going to use Python. I think the code reverts to Java for part 3 where the author tackles 'Patterns for Test-Driven Development.'

The first two parts of the book very much support the 'by Example' of the title. In part one he uses the development of currency support and in part 2 walks you through the design and implementation of a testing framework.

The book is written in many small chapters which is an example of text emulating method because one of the authors continued themes is that we should proceed by small steps. In other words he advocates a form of minimalism, do not do more than you have to and do not do more than one thing at a time. The result is that we have a book of 32 chapters packed into 205 pages. As he always starts a new chapter (and part) on an odd numbered page, you will find quite a few (21) completely blank pages plus an average of half a blank page per chapter. That makes the average chapter between five and six pages. But that is exactly the right message for this book.

The second message of this book is that you should write your tests to fail. By that I mean you should imagine what could go wrong and then test for that. Let me give you an example from some code I was writing recently where I needed to find the Polar co-ordinates of a point that was provided in Cartesian form. What can go wrong? Well the y co-ordinate might be zero. How can we tackle that? Well the very first thing is to write a test that tests exactly that case. The next thing is to realise that using an arc tan for the special case must be a common problem, so look at the Standard Library and find

arctan2()
. That is not the end of the problem, because that only deals with division by zero (by side -stepping it). We also need to test for the case when both x and y are zero. That test will quickly force us to revise our code for calculating an argument by handling the special case.

This book will have little to offer if you already take a minimalist approach to your code writing (or as I describe it, never do anything till you have to) coupled with writing tests to detect assumptions (How I wish teachers and instructors would write such tests and apply them to their students work - good students would pretty quickly catch on to writing their own tests to ensure their assignments passed. Actually those with a degree of entrepreneurial sense might charge a small fee for pre-testing the work of the idler students). The rest could benefit from considering this approach and reading this book could help.