π§π»ββοΈ Putting Test-Driven Development under Trial: Could the Critics Be Right? π³ Part 2 (fixed)
Here is the 2nd part of our investigative journey where the practice of TDD is put on trial. The prosecuting attorney presents the arguments against TDD, raising doubts about its effectiveness.
π π’ Newsletter Update Time π’
π Milestones Reached π
π Hey, developers! Welcome to the home of continuous improvement and learning for Software Developers.
π In case you missed it: this is the second part of an imaginary trial: we are trying our best to prosecute TDD, supporting all the critics that are typically moved against it - and then trying to defend it, supporting both points of view with the most concrete approach possible. In case you missed it, check our archive for the first part.
π₯ Premium updates π₯
π₯ Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.
Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more π here.
Thanks again for being a part of our journey! π
π£ Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesnβt expire! π
π§π»ββοΈ Putting Test-Driven Development under Trial: Could the Critics Be Right? π³ Part 2
Introduction
Sorry, a wrong email started yesterday. This is the correct email with the complete introduction. Sometimes, we just make a mistake - sorry again. Enjoy the issue! πͺπ»
Few practices in software development have sparked as much debate and controversy as test-driven development (TDD). Advocates think it's a panacea for writing clean, manageable code, while critics argue it's a time-consuming and unneeded burden. Last week, we started a trial on TDD. Imagine a courtroom in which the prosecution throws charges and the defense rallies to demonstrate that those charges are wrong.
I collected all the critics I found online about TDD, and we are giving all those critics the benefit of the doubt, trying to go very deep into understanding the cons that they typically suggest and to support their ideas - then, we will also try to demystify it. In the end, I will share with you what thoughts I had after all this work.
So grab your gavels and robes, for we're about to embark on the second part of the TDD trial of the century! ποΈπ©βπ»π¨βπ»
k to the Trial π
Here is the updated list of the 8 most common criticisms that people throw against TDD - a list I collected by searching online and from past experiences and chats, and we already discussed the first 4 points in the first part last week:
Time-ConsumingToo much overheadFocus on Testing, Not DesignInflexibilityOver-testing
Difficult to Learn
False Sense of Security
Not Suitable for All Projects
Today we will continue our ping-pong challenge between the prosecution and defense of TDD, completing the list with the last 4 points and then going straight to the conclusions.
TDD cause over-testing
Prosecution
Ladies and gentlemen of the jury, let's restart this trial by delving into another pressing issue surrounding Test-Driven Development (TDD). Detractors claim that TDD, in its zealous pursuit of robust code, can inadvertently lead to over-testing. The concern is that developers, driven by the TDD approach, might find themselves entangled in an exhaustive quest to cover every conceivable edge case.
This meticulous testing, as critics argue, can be a time-consuming and unnecessary endeavor. Picture this: developers navigating a labyrinth of test scenarios, trying to account for every possible nuance. We must ponder whether this exhaustive approach to testing is truly warranted or if it's an undue burden on the development process. As we proceed, we'll unveil the intricacies of this claim and explore whether TDD's emphasis on comprehensive testing is a necessary virtue or an onerous vice.
Defense
Your honor, and ladies and gentlemen of the jury, please excuse me but Iβll have to be repetitive on this one - because once again, the prosecution against TDD has no concrete pieces of evidence.
As I mentioned last time, Kent Beck shows us how the same problem caused him to write 6 tests, while another developer wrote 65. Quoting the book:
You will have to decide, from experience and reflection, about how many tests you want to write.
TDD's view of testing is pragmatic: tests are a means to an end, the end being βcode in which we have great confidenceβ. The number of tests we decide to write will depend on the confidence we have in the problem and a possible solution.
There is another thing that most often is not considered: tests in TDD lead you to a solution, but then you only want to keep with you the tests you need to feel safe when that code changes. Itβs not uncommon that once your work is done, you might consider throwing away some of the tests that you used - because they already fulfilled their purpose in driving you through design decisions but they donβt add any confidence when changing the code.
TDD is hard to learn
Prosecution
There is another contention against Test-Driven Development (TDD) that we want to highlight today. Critics vehemently assert that TDD, with all its purported benefits, presents an insurmountable challenge for developers new to the practice. The crux of the matter is the formidable learning curve associated with TDD, which, according to the prosecution's argument, may serve as a deterrent to its widespread adoption.
The prosecution contends that TDD is not just about mastering the art of testing; it entails delving into the intricate principles that underpin effective test-driven development. This dual challenge, critics argue, places an undue burden on developers, especially those navigating the early stages of their TDD journey.
Defense
There are two sides to the medal when discussing the learning curve of TDD: first of all, it requires a shift in the way we think about problem-solving. Most of us learned to develop software in a specific way: code a solution, then test it. TDD requires a shift where you think about your tests before writing the actual code - and not only at a high level but also for every step we make in coding the solution.
The second point is that TDD also brings the approach of small steps and continuous design feedback thanks to the TDD cycle and the fact that we execute the test suite every minute; we are all typically so used to working with long-living branches and getting feedback only after a lot of time - and even if that late feedback is often uncomfortable, a lot of people think it is inevitable.
To learn TDD, you need an Agile mindset: you need to embrace change to accept that there might be another way to do things, maybe even better ways.
TDD is a way to ensure that you produce βclean code that worksβ, having a simple way to avoid bugs and defects or recognize them very early when they happen; itβs a way of doing one thing at a time, to avoid being overwhelmed by a lot of ideas when coding; itβs a way to improve the design one small step at a time, without getting stuck in implementing a certain design patterns because the step was too big.
Iβve never seen someone having a great level of confidence in those without TDD, and even if you can do it, ask yourself how much energy it requires you - with TDD, itβs all included.
TDD gives a false sense of security
Prosecution
We are not done yet, and now let's delve into another critical assertion against Test-Driven Development (TDD). Detractors argue that the pursuit of extensive test coverage, a hallmark of TDD, might inadvertently foster a false sense of security among developers. The crux of this contention is that developers, ensconced in a cocoon of extensive testing, might be led to believe that their code is impervious to bugs.
The prosecution posits that an overemphasis on test coverage could be a double-edged sword, providing a deceptive assurance that the codebase is devoid of defects. As we scrutinize this claim, we'll explore whether the purported sense of security induced by comprehensive testing is a commendable outcome or a perilous illusion that detracts from the rigor of software development.
Defense
No one advocating TDD will ever tell you that if you do TDD you will never have defects, bugs, or any problem. It would be just false, anyway.
TDD is a way to minimize unplanned work, which includes bugs and defects for sure. Minimize doesnβt mean avoiding completely - you can always make mistakes, for sure, even if TDD minimizes the fact that a mistake is integrated into the main branch and reaches production or even staging. But it can happen because we are humans.
Doing TDD doesnβt change the fact that you should have a good monitoring and alerting system - or more in general, a way to notice problems immediately when they happen, a good rollback strategy if required, and also working in Continuous Integration releasing a small batch of work every day so that even if an issue shows up in production the change will be very little and fixing it will be very fast.
TDD is not a replacement for that, for sure.
TDD is not suitable for all projects
Prosecution
And finally, your honor, let us now address the last critical viewpoint we want to level against Test-Driven Development (TDD). We want to contend that TDD may not be the optimal strategy for projects characterized by swiftly evolving requirements or those in the throes of highly experimental development.
The prosecution submits that TDD's insistence on defining tests before actual code might pose a challenge in the context of projects where requirements are in constant flux. We shall examine this claim closely, scrutinizing whether the rigidity of TDD aligns with the demands of dynamic and experimental development environments or if it becomes a hindrance in such scenarios.
Defense
Well, your honor, here we have something that can be partially true, but⦠the reasons why this can be true are completely different from what the prosecution suggested.
Is TDD suitable for all projects? Yes, it is. Itβs also suitable for startups and small businesses because it will cost less money spent on developing software, most often because of less time invested in giving the feature to customers and reduced unplanned work. βAccelerateβ (the book) proved this in the research it is based on.
Is TDD suitable for any coding situation? Maybe not, as always there are special cases.
For example, when you are doing a spike or some thinking around code, you might want to avoid tests, at least at the beginning, because you are just looking around and you donβt have any clear questions to respond to. Once you have it, Test-First is a good way to formalize it, for example, but you might decide to follow TDD strictly or not depending on the situation.
Well, this fake trial finally ended - and it was a good, fun exercise to try to collect all the concrete ideas against TDD and also try to debunk them afterward.
As you all know, I love Agile Practices, but I also want to be sure that it doesnβt become a dogma where Iβm not able to recognize the reasons why it is good anymore - so I feel that sometimes trying to discuss against it, even internally, is a good idea.
What do you think? Reply to the email to let me know what you think about TDD and if you practice or are interested in learning it!
Until next time, happy coding! π€π©βπ»π¨βπ»
Danβs take ππ»ββοΈ
I will not add much today, because the target of the trial is to try to be non-opinionated most of the time, but hey - this is my personal take zone, so itβs opinionated by definition.
First of all, I want to say that it was really fun to build this fake trial: I used Chat GPT to help me write the prosecution part in an attorney language, and after a couple of prompts tests, I was able to get a good enough result, hopefully!
As always, collecting points against something I love is a great exercise: it makes not only reflect on some elements that are actual criticism, but also reminds me of why such practices are great, which is always important to avoid them becoming a blind dogma.
Here are some reflections I made in the process:
A lot of people consider TDD time consuming, while today Iβm a lot slower when I donβt write tests before; this makes me reflect a lot on the fact that a lot of people donβt learn enough about something before using it in the real world, and this is bad - whatever it is that βsomethingβ. We should consider writing software for production more like a match for a professional sport: itβs our performance, and at that moment we have to win in any way (in our case, getting the result with the lowest cost possible) - it is not the moment to βtry something new I never tried beforeβ, for that you should the training to build the confidence you need to then use it during the real performance.
Resistance to change is a real thing for human beings, and itβs hard to fight. But since I started to talk about TDD around, and hosting workshop, I realized that a lot of people just need a bit of support - they start learning TDD but they are not pushed by the environment in growing into that direction, and then it requires a huge willing power to keep going on; if you want to learn TDD and you are having hard times, before giving up, find a mentor!
The βthere is no silver bulletβ and βthere is always a trade-offβ are very useful quotes, but sometimes we use them to hide ourselves from the truth. I want to be completely honest: I still havenβt found any actual cons to TDD. I keep looking for it because I want to be a critic to grow even more, but I canβt find it. Iβve never seen someone doing TDD and regretting it or highlighting limits - Iβve always seen people who find it hard and then start arguing against it. TDD produces better software, itβs a fact.
Kent Beck says: βIβm not a great developer - Iβm just a good developer with great habitsβ. I follow this quote daily, building better habits to avoid facing big issues.
If I prevent the fire, I donβt need to learn how to face it.
Go Deeper π
π Books
Test-Driven Development: An Empirical Evaluation of Agile Practice - this book includes the results of three different experiments, including concrete examples of how to conduct statistical analysis, using as evaluation indicators the number of acceptance tests passed (overall and per hour) and design complexity metrics.
Test Driven Development: By Example - the original book from Kent Beck that explains TDD, with examples, and also explain some pitfalls for experts practitioners
Learning Test-Driven Development - Author Saleem Siddiqui shows you how to tackle domain complexity using a unit test-driven approach. TDD partitions requirements into small, implementable features, enabling you to solve problems irrespective of the languages and frameworks you use.
Growing Object-Oriented Software, Guided by Tests - Implementing TDD effectively: creating cleaner, more expressive, more sustainable code using tests.
π© Newsletter issues
Everything I know about introducing TDD in an org [The Engineering Organisation by svs]
Introduction to Predictive TDD [Make Your Code More Testable by Ted M. Young]
Use Test-driven Development to Retain Modularity [Crafting Tech Teams by Denis Δahuk]
π Blog posts
ποΈ Podcast episodes
TDD for today [Thoughtworks Technology podcast]
Unit Testing With Test Driven Development [Complete Developer podcast]
TDD with Ian Cooper [The Unhandled Exception podcast]
π¨π»βπ« Online courses
Test-driven Development: CodeMash [Pluralsight]
TestDriven.io [a platform dedicated to TDD courses]
TDD micro-learning - Our micro-learning courses catalog offers, among the others, a path dedicated to TDD: learn the core concepts at your own pace in an interactive learning experience
π΅οΈββοΈ Others
β‘οΈ How effective is Test-Driven Development - a research written by the University of Oulu, Carnegie Mellon University and Fraunhofer Center for Experimental Software Engineering
β‘οΈ Quora post from J.B.Rainsberger about TDD effectiveness