Like many Agile approaches, the principles of Test-Driven-Development (TDD) and its Red-Green-Refactor cycle seem deceptively simple. As often, things are more complicated in practice and this is why Jason Gorman wrote a 200 pages book about TDD that explores the multiples dimensions of this approach.
If the book TDD from Jason Gorman presents naturally in details the main process behind Test-Driven-Development, it explores also some of the associated topics that are less often discussed like working with a customer, continuous integration or dealing with legacy code. The book is well-structured, with a practical code-oriented approach and filled with examples. It uses Java as a programming language, but it can be used by all coding platform.
I will recommend this book to every software developer and software tester concerned by code quality, whether they work in an Agile context or not.
Reference: Codemanship TDD, Jason Gorman, http://www.codemanship.co.uk/
Quotes
Seven decades of computer programming history has taught that us that our code will almost certainly need to change. If code is difficult to understand, complicated, full of duplication, and too interconnected, then it will be expensive to change. TDD explicitly includes a discipline called refactoring that helps us to keep our code as easy to change as possible.
The key to communication is ensuring every stakeholder’s internal mental model is roughly the same. That means we all need to be speaking the same language. If software design is all about solving the customer’s problem, it stands to reason that the language we should all be speaking is the customer’s language.
When it comes to the quality of our code, we often have the best of intentions to go back and code issues that might get in our way later. Inspection of hundreds of code bases, however, teaches us that – nine times out of ten – we never actually get around to it fixing problems we leave behind. For that reason, I strongly recommend that you refactor until you’re happy leaving the code as it is – because you very probably will leave it like that forever. That makes the third step in the TDD cycle extremely important. It reminds us to clean up our code to make it as readable, as simple, as free of duplication and as modular as we can before moving on to the next failing test.
What we should generally not do is invent non-functional requirements without consulting the customer, and speculatively optimise our code “just in case”. Let the customer’s needs and real technical constraints (budget, hardware, legal compliance, etc) drive your non-functional tests. And relate the non-functional tests directly to functional customer tests wherever possible, so you can be sure that you and the customer are talking specifics. When you talk about a feature being used very frequently, be sure which scenario you’re referring to. Withdrawing cash from an ATM may occur frequently, but an edge case like the mechanism that dispenses the notes jamming occurs very rarely.