TDD mental model
TDD is always a hot topic that fills the web and social media with discussions every day, but there's an important element of TDD that often gets ignored: the mental shift it brings!
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Let's dive into today's micro-topic!
The mental shift that comes with TDD
Test-Driven Development (TDD) is a Software Development practice where we start the development of new behavior in our code by writing tests, in a continuous ping-pong between adding a new piece of test and implementing the code that passes that test, all while keeping the code clean with continuous refactoring. I will assume you have a good understanding of what TDD is - if it’s not the case, I suggest you look at this great article from Martin Fowler’s blog before moving on with this issue.
TDD is always a hot topic that fills the web and social media with discussions every day. The most common discussion typically involves:
How to learn TDD
pros and cons of this practice
technicalities and different approaches
the struggles people find when approaching the practice
But here's the thing: there's an important element of TDD that often gets ignored.
Test-Driven Development is a completely different approach to Software Development, that brings a completely different mental model for the developers.
This is related to one of the most-known quotes about TDD:
TDD it’s not just about writing test first.
“Test-First Programming” is part of TDD, for sure - but it’s just one piece of the TDD puzzle.
When you develop in TDD, you are using tests to drive your decisions about all the characteristics of a piece of code:
interfaces
names
design
architecture
… etc
All these decisions are taken constantly, on the next piece of code we are writing, tests included - but we take them constantly on very small pieces of code, making them a lot easier.
Let’s see an example of the first test of a FizzBuzz kata:
start writing a test:
name it
testItConvertsNumber1toString→ we already decided that the input is a number and the output is a stringinstantiate a class named
FizzBuzz→ we just decided how our class will be namedcall a method
convertpassing the param1→ we just decided how the method will be named and confirmed the param type… and so on
We already made a lot of decisions, and we have just a couple of lines of code, and this will continue iteratively.
Anyway, the main advantage of TDD from the mental approach to our work imho is related to tests themselves: once you become proficient in TDD, and it becomes your daily way of working, you will realize that some habits you had before are not part of your daily routine anymore:
debugging: once you are used to writing in small steps, with tests first, you will not need to debug anymore because when things break the change is so easy that investigating is also easy
understand your progress: the test and test lists tools used in TDD will make the progress and the idea of “done” very explicit and visible
But the most important habit to throw away is asking yourself questions about testing like:
what do I have to test here?
how much time left do I have to add tests?
can I not have tests at all here?
There is just no choice: you will realize that in less development time (because TDD helps with YAGNI), you obtain a better design with tests included, no need to ask additional questions on them - and you will notice how unplanned work is reduced therefore you are reducing the costs for your company.
TDD flips our mindset by making writing tests an integral part of the development process. Here's the kicker: both the production code and tests emerge from the same piece of work. No more of that "done now, test later" feeling that leaves us scratching our heads at the end of the development process to understand how to move on and “if it’s worth” adding tests, how many, etc.
Think about it: testing after often leads us to treat tests as an afterthought, potentially devaluing their importance. But once you become fluent in TDD, you'll find yourself zooming through software development faster than ever, with the added bonus of having tests generated along the way with no additional work.
When we evaluate practices like TDD, we need to set our perspective on a team level. We need to consider the impact on the bigger picture: the overall system, team outcomes (not just individual wins!), and the benefits for the company as a whole. Here's where practices like TDD shine: they prevent the issues we usually struggle with. It's not about remembering to test or convince the higher-ups—it's seamlessly part of the development process, with zero added cost.
I do not deny that there is a learning curve to TDD, but this is inevitable with any practice. But trust me, the investment pays off big time. In just a few months, maybe a year at most, you'll look back and realize your career has taken a remarkable turn for the better.
🧠 Test Yourself in 1 minute:
💡 Did you know? An interactive activity, like quizzes or flashcards, can boost your learning!Take advantage of our set of Flashcards dedicated to this topic: read the word and try to describe its definition - then turn the card to check the correct one for feedback 😲 Don't miss out on the opportunity to boost your learning—try now!
Test-Driven Development (TDD) is…
Insights Recap
Test-Driven Development (TDD): develop code in baby steps in a continuous cycle of writing a test that fails for a small piece of behavior, passing that test, refactoring a bit, and so on.
TDD is a hot topic, discussions typically involve:
How to learn TDD
pros and cons of this practice
technicalities and different approaches
people struggle with the practice
An important element often underestimated about TDD is the different mental shifts it brings
“Test-First Programming” is part of TDD but it’s just one piece of the TDD puzzle
With TDD you use tests to drive all the decisions you have to make about the code
Once TDD becomes your daily way of working, you realize that some habits you had before are gone:
TDD makes explicit the progress of the work
TDD usually removes the need for debugging
But the most important habit to throw away is asking yourself questions about testing at the end of the process, making it look like an additional piece of work that can be skipped to be faster, which is a trap
With TDD, production code and tests emerge from the same piece of work
With TDD, you will develop software faster than ever, with the bonus of having tests generated along the way with no additional work
When we evaluate practices like TDD, we need to set our perspective on a higher level: the benefits of team outcomes and company success are concrete
There is a complex learning curve to TDD, but this is inevitable with any practice - and once you master TDD your career has taken a remarkable turn for the better
Until next time, happy coding! 🤓👩💻👨💻
Go Deeper 🔎
Legenda
📚 Books
📩 Newsletter issues
📄 Blog posts
🎙️ Podcast episodes
🖥️ Videos
👤 Relevant people to follow
🌐 Any other content📩 Canon TDD (Software Design: Tidy First? by Kent Beck)
📩 Why TDD Enhances Developer Productivity (Craft Better Software)
📩 A TDD Hello World (Small Batches)
📄 Test Driven Development is the best thing that has happened to software design
📄 Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software
📄 🧑🏻⚖️ Putting Test-Driven Development under Trial: Could the Critics Be Right? 😳
🖥️ Introduction to Test-Driven Development (TDD) with TypeScript | 2021