Why TDD fails in practice

I found a big problem that remains unsolved in our industry - how to practice TDD in legacy code? I found the solution after many years.

Nov 25, 2024

👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. To get these articles in your inbox every week, subscribe:

1. The failed attempts to apply TDD in practice

Software engineers try to learn TDD by:

Reading TDD books
Watching TDD courses
Hunting on the internet

This is what Engineering Leaders tried:

Buying Udemy & Pluralsight subscriptions
Arranging TDD trainings for employees
Introducing 80% code coverage thresholds

It didn’t work.

Why?

Because the examples used were generally simple katas. They didn’t address legacy code, instead they just showed how to apply TDD on a clean slate. And they only show TDD at a specific level (e.g. how to apply at the Unit Test or Acceptance Tests level) - they don’t show you the big picture.

The books / courses / trainings DON’T tell you how, given a User Story, with multiple teams, in legacy code, where to start…

2. The problem: Applying TDD in legacy code

The majority of developers are working on legacy code. “Legacy code“ doesn’t mean old code, it actually means “code without tests”:

“To me, legacy code is simply code without tests.”
- Michael Feathers, Working Effectively with Legacy Code

The problem isn’t just that the code has no tests, but that it’s untestable, making it impossible to write tests at all, thus preventing us from practicing TDD. But to make the code testable, we would need to redesign it for testability, but this itself is a huge risk; it’s too risky to touch anything.

So we’re trapped.

3. After many years, I found the solution

I spent years coaching teams to adopt TDD. I worked with various teams across the globe, in different industries, developing different products.

Over time, a solution ”emerged.” After seeing the pattern in how to apply TDD to legacy code in real life projects, I decided to translate it to a Sandbox Project that you can make, and learn the skills before applying it to your project at work.

I know that software engineers are already busy and under a lot of stress. They might be working overtime due to low quality. They don’t have the time to read 200 page books, to watch hours of courses, and then try to apply it with trial-and-error, and perhaps after years, coming to a solution. I know that you’re busy, and that you don’t have time to wait. That’s why I’m giving you the solution step-by-step to accelerate your journey.

I know that Engineering Leaders face challenges since many teams don’t practice automated testing at all, let alone TDD. That problem can’t be solved through Udemy nor Pluralsight nor 2-3 day TDD trainings. The developers are left off at an even worse level, they try TDD, it doesn’t work, they give up and then become resistant to it. The attempts to apply TDD are too risky and too slow. Engineering Leaders need a roadmap to introduce TDD in a scalable way across teams. That’s what I’m sharing with you.

TDD Bestseller

The core problem: Applying TDD in practice appears impossible. Even though we know that TDD is the most effective way to produce a reliable test suite, and that a reliable test suite is essential for delivering software in a safe and fast way, we have no idea where to start in real life projects. Books, courses and trainings don’t help, because they use simple katas which aren’t relevant to real life projects.
The practical solution: Step-by step TDD in Legacy Code Transformation. I discovered the process of introducing testable architecture, introducing automated testing, and introducing TDD in real life projects. I’ll guide you in a hands-on way using a Sandbox Project, that you can translate to your real life project.

I was so excited when I opened up my email last week, to find this message from Substack, that I became a Substack Bestseller!