Test-driven development is a technique for designing and structuring code that encourages simplicity and increases one’s confidence in code, even as its size increases.
…this technique is borne of a set of beliefs about code, namely:
- That simplicity—the art of maximizing the amount of work not done, is essential.
- That obviousness and clarity are more virtuous than cleverness
- That writing uncluttered code is a key component of being successful.
…The unit tests that we end up with via TDD are an added bonus; the primary benefit is the simplicity of design we get.
How do we achieve this simplicity? It is through the mechanism of red-green-refactor…
…TDD guides us to simpler design because it provides these two practical rules as guardrails: Only write production code to fix a failing test. Refactor energetically when, and only when, tests are green.
– Learning Test-Driven Development, Saleem Siddiqui
As a Business Analyst at a company operating under the waterfall paradigm, I was trained to do all the analysis up-front, before any code was written. The development team was outsourced, so once our extensive documentation was written and sent over, we would essentially sit and wait for the updated code to be delivered. Once received, we would go through the painstaking procedure of testing all the changes to see if they worked. There were always defects to be logged, which was to be expected – but all-in-all, as long as the team hadn’t completely misunderstood what you wanted, things turned out OK. The developers presumably did their own testing before delivering their work, but I never saw what that testing entailed.
When I moved to work for a more Agile company, the way of working was quite different, and while I had initially held onto a mindset that all the thinking should be done up-front, and that testing is primarily done after the code is written (and done primarily by hand), it quickly became apparent that this is not how high-performing teams work.
That particular cat cannot be put back in the box. Now, the more I learn about Agile, the more interesting it gets. The fact that the material and best-practice is so connected makes it a very satisfying thing to learn about. As argued in Accelerate: The Science of Lean Software and DevOps, implementing a DevOps culture correlates with high performance. The cornerstone of DevOps is continuous delivery; the first step toward continuous delivery is continuous integration; and the key requirement for continuous integration is automated testing. And this is where we get to this book: Learning Test-Driven Development, by Saleem Siddiqui.
I had had it all wrong; it’s not design, then build, then test – it’s more like “aid your design through tests, and then build”. As someone who is improving their development skills, it only made sense to learn about TDD, because from what I had understood, it transforms how you work as a developer and your relationship with your code.
The book did not disappoint. It was fairly light on the motivation and benefits of TDD – early on stating that it expects you to be sold on the concept already, or willing to give it a go – and goes straight into the coding examples. I followed the book in JavaScript, though the book provides code for Go and Python as well. The fact that these languages were used (and with modern syntax, given the book’s recent publication) was the main reason I chose it over Kent Beck’s more well-known book on the topic.
I feel I understood the RGR (Red-Green-Refactor) cycle by the end, and was able to continue on to do my own practice, however, given the book is quite short, the examples never got particularly complex, and so the tests were always quite simple. As someone being introduced to TDD in practice for the first time, it did leave me wondering how realistic the examples were, whether my tests should really be this small, and how quick-and-dirty I should be in my efforts to get to ‘green’ before refactoring. The latter is the main point of uncertainty to me – the book didn’t really elaborate on why I should focus on getting to Green and then Refactoring, as opposed to getting to Green via good quality code to begin with (making the cycle just R-G, I guess).
I’m sure some aspects of TDD become more plain with practice, and I can hardly expect a comprehensive deep-dive on the subject from a book that (especially if you follow only in one language and therefore only read about half the pages) is quite short.
Overall, the value of the book was well, well worth the time it took to read it, and I feel comfortable adding TDD to my tool-belt.
A new book on TDD by Rob Myers will be published in February 2024, which I might pick up if I want to read more. It’s Mike-Cohn-approved which is basically all the reason I need!
Leave a Reply