Author: Kent BeckPublisher: Addison-Wesley, 2003
ISBN: 0321205685
220 pages
Author: Kent Beck
Publisher: Addison-Wesley, 2003
ISBN: 0321205685
220 pages
Benefits of Test-Driven Development: Kent Beck, in the preface to this book mentions Ron Jeffries' pithy phrase, 'Clean code that works', and suggests that this is the goal of Test-Driven Development. The benefits of clean code that works from Test-Driven Development are many according to Kent who I quote (italics mine)":
The above benefits are enormously good for developers as these things enhance their self-worth, confidence, and de-stress them, while at the same time increasing the value of their outputs for teammates and users alike. Although Kent doesn't mention productivity gains from better outputs and cost reductions, I know that these would be natural results of well-implemented Test-Driven Development. When a developer feels good, and when he/she focuses on testing (read 'critical thinking', which is what an early testing approach encourages) good things such as increased quality, and reduced costs and time are bound to follow.
The book is organised in three parts:
Each of these Parts contains a technical example, which would be best understood if the reader actually physically coded the example as Kent progresses (in the book) through the detailed approach to Test-Driven Development. (Some good developers, I'm sure, could follow the examples with ease without starting up a development environment.) For readers who are less technical, or who don't have the time or inclination to code with Kent, there are still plenty nuggets of learning and insight to be taken from Kent's words and commentary in between and around the actual examples. These less technical readers will, however, have to work harder to gain the value contained in this book.
Test-Driven Development, it may interest you to know, follows only two simple rules:
These two rules suggest an ordering of programming tasks Red/Green/Refactor - Red/Green/Refactor - and so on, where Red means to write a test (which initially will most often not work), Green means to make the test work, even if by writing 'dirty' code, and Refactor means to remove duplication introduced by each new test.
Following the two rules in the Red/Green/Refactor cycle results in developers having to:
Kent explores patterns at lower technical levels and also looks at higher system/acceptance and business levels in this section. I enjoyed Kent's realisation that writing code which is demanded by failing tests (Test-Driven) has social implications, and it was exciting to read the technical and social conclusions he came to in some instances, or the direction his thoughts were going towards in others. Kent's thoughts are built up, step-by-step (dare I say Red/ Green/Refactor?), and the reader can't but be involved in reaching many of his same conclusions - almost feeling as if you, the reader, have come up with these bright ideas yourself.
Kent's view of testing is rightly focused on the detailed technical level. It is here that he is correct to show how and why a developer should create and maintain an up-to-date set of tests, which are run often - at least as often as on every change. These tests should be designed to be independent of one another, so that they could be run in any order or in isolation. Catering for tests that meet these characteristics helps developers to design highly cohesive, loosely coupled solutions which are easier to scale up and to maintain. When developers use tests to determine which code to develop, project solution scope is better controlled. By including assert statements with simple and self-explanatory test data Test-Driven Developed code carries self-documented tests with it - and this is maintenance heaven (the only drawback is that this code rarely fails and so developers can't spent long periods here - they will spend more maintenance time where code was not primarily delivered by the Test-Driven Development approach!)
Kent describes, in Part III, the mastery of Test Driven Development. Chapter 32 poses various important questions that Kent answers in the text. If you would like to know the answers to the following partial list of questions, you had better think about buying the book!
Interesting Asides: Kent makes a serious, technical book much more palatable with his dry humour and sometimes quirky asides such as the following gem on page 125: "When I was a young programmer - long, long ago when we had to dig our own bits out of the snow and carry heavy buckets of them barefooted back to our cubicles, leaving bloody little footprints for the wolves to follow….Sorry, just reminiscing." This is his own brand of delight - no doubt drawing from real life stories such as, "when I was young 'real' programmers used to have to wire the memory cores with their teeth" or, "I knew a programmer who could submit 1024 punch cards and have them clean compile first time around!"
Is this the Future of Testing? I've heard from sources outside of this book that Kent Beck once proclaimed at a software testing conference that professional testers would no longer be required (presumably when all developers adopted a Test-Driven Development or a similar approach). Kent, needless to say, put the cat amongst the testing pigeons on this occasion! I've heard reports that he has moderated this view somewhat and in fact the book does carry some insight in this regard: Kent outlines three types of testing that Test-Driven Development does not replace, namely: performance, stress, and usability testing. Other testing types not mentioned by Beck, but which are also unlikely to be replaced by Test-Driven Development are security, data integrity, installation, back-up and recovery, interface, integration, system, acceptance and configuration testing, although I do believe that Test-Driven Development would contribute towards less effort spent on these testing types by reducing defect densities during the design and coding stages. Of course testers would also have to be sure that developers did apply Test-Driven Development principles, and they would have to do some testing to confirm this.
In a section on 'Test Quality' Kent reveals his innermost thoughts on and attitude to the profession of software testing, "… if the defect density of test-driven code is low enough, then the role of professional testing will inevitably change from 'adult supervision' to some-thing resembling an amplifier for the communication between those who generally have a feeling for what the system should do and those who will make it do it". One could ask, "who are those that generally have a feeling for what the system should do?" Here Kent is onto a big point - many inaccuracies, contradictions, ambiguities, and holes exist in the communications from the business community to the developers. It is particularly here where professional testers can and often do clarify (Kent uses amplify) expectations and remove defects before developers create a clean product that works, but perhaps a product no one wanted or specifically asked for.
It is a Technical book: In the preface, Kent mentions that several reviewers commented that they got most out of the book when they started up a programming environment, entered the code, and ran the tests as they read. Although I did not do this myself, I can quite believe it to be true. The book is technical and is in my opinion a good guide for developers or test automators seeking to write 'clean code that works'. I wish I knew how to encourage every teaching institution to introduce this method of programming to their developers. The fact that not all developers do code using Test-Driven Development is however a blessing for me - I own a software testing company - and if developers consistently used this approach I think we would not be able to bill so many hours reporting the vast swathes of defects still commonly produced and not developer-detected in many Test-last-if-ever Development approaches!
Kent is a developer through-and-through and has directed this work squarely at developers. He does not often mention (if at all) business persons, business analysts, project managers and even system architects. The testing community, however, has obviously caught Kent's attention. Testers everywhere can be grateful that Kent now enthusiastically supports and promotes within the development community, a test-up-front attitude - a very fundamental aspect of modern testing thinking and practice.
Do I recommend the book? Yes, specifically for developers in training, or for more experienced developers who have not yet had any training in software testing or in Test-Driven Development. I recommend that managers who wish to receive 'clean code that works' ought to get copies of this book for their developers. Testers intimately involved in white-box testing, and test automators should also definitely acquaint themselves with Test-Driven Development, and Kent's book is the best place to start - it is already in its 5th printing.
Nice work, Kent.
Wayne Mallinson