Doing TDD improved my DevExp

A long time ago, I had worked on a project that had no tests whatsoever. In fact, I was working in a team dedicated to fixing bugs, which was called the Support LVL 3 team. It was awful, could you imagine spending your whole days just getting bugs to fix and never creating anything new, and eventually getting a bug that you had fixed before again? Well, that was my reality. After a few months there, I was already feeling, something was not right, and I had no idea how we could actually avoid such problems, and that was the moment I learned about automated testing. Well, unfortunately, it wasn't in that project that I started applying it, at that moment, for many people that I worked with, there was a belief that tests would slow us down. Shortly after leaving that company, I went to a place where I was incentivized to test my own code. It wasn't TDD yet, but it was some advance. I could finally stop seeing regressions, and would not have a team dedicated only to fixing bugs, which was awesome. I was still not producing my best code, though, and sometimes, I would write tests that were so broad that in case of a bug, I would still spend a few hours debugging to figure out where the error was. A few years down the road, at a conference, I came across this talk about TDD, and then I got hooked. The speaker wasn’t just talking about tests—he was talking about design, focus, and developer flow. He explained how writing tests first could lead to more modular, predictable, and clean code. It sounded almost too good to be true. But the examples were so simple, so intentional, that I left the room thinking: “Why haven’t I been doing this all along?”. Well, when I first started applying, it looked somewhat less obvious. I started playing with it on side projects, but I wasn't somehow getting the benefits. I would write this test, add the code, change the test, then be like, am I doing this wrong? I saw some people use TDD and handle it with an elegance and speed that I could only assume was from some years of experience, while I felt like I was constantly tripping over myself. Wasn't this meant to speed up my work? I even began to question everything, even as if maybe my first team was right - Tests maybe slow you down. What if this was all just theory that did not really work in the real-world development? I decided to keep researching, though, and keep trying it out. During this research, I came across another incredible talk, "TDD, Where Did It All Go Wrong" by Ian Cooper. That talk changed everything. I finally understood what I was doing wrong. I was testing the code, not the behaviour I wanted to achieve. I was creating a highly tight coupled test of my implementation details. That’s why it felt painful. That’s why it wasn’t working. Armed with that new perspective, I gave it another go. And this time, it was different. I stopped trying to test everything. I focused on testing what mattered. I stopped coupling my tests to how the code was written and focused on what it should do. My tests became simpler. My code became more expressive. And that is the reason I can say that applying TDD rightly improved my DevExp. After learning how to do it properly, I finally got the benefits everyone talked about. I started having fewer regressions, faster feedback, and having more time to do what I really like to do: build great software products. If you are still figuring out what TDD is and if you should use it, that's ok, just keep practicing, because one day it will click, and when it does, it will be like pulling back a curtain to reveal a scene you didn't know was there.

May 2, 2025 - 10:55

A long time ago, I had worked on a project that had no tests whatsoever. In fact, I was working in a team dedicated to fixing bugs, which was called the Support LVL 3 team. It was awful, could you imagine spending your whole days just getting bugs to fix and never creating anything new, and eventually getting a bug that you had fixed before again? Well, that was my reality.

After a few months there, I was already feeling, something was not right, and I had no idea how we could actually avoid such problems, and that was the moment I learned about automated testing.

Well, unfortunately, it wasn't in that project that I started applying it, at that moment, for many people that I worked with, there was a belief that tests would slow us down.

Shortly after leaving that company, I went to a place where I was incentivized to test my own code. It wasn't TDD yet, but it was some advance. I could finally stop seeing regressions, and would not have a team dedicated only to fixing bugs, which was awesome. I was still not producing my best code, though, and sometimes, I would write tests that were so broad that in case of a bug, I would still spend a few hours debugging to figure out where the error was.

A few years down the road, at a conference, I came across this talk about TDD, and then I got hooked.

The speaker wasn’t just talking about tests—he was talking about design, focus, and developer flow. He explained how writing tests first could lead to more modular, predictable, and clean code. It sounded almost too good to be true. But the examples were so simple, so intentional, that I left the room thinking: “Why haven’t I been doing this all along?”.

Well, when I first started applying, it looked somewhat less obvious.

I started playing with it on side projects, but I wasn't somehow getting the benefits. I would write this test, add the code, change the test, then be like, am I doing this wrong?

I saw some people use TDD and handle it with an elegance and speed that I could only assume was from some years of experience, while I felt like I was constantly tripping over myself. Wasn't this meant to speed up my work?

I even began to question everything, even as if maybe my first team was right - Tests maybe slow you down. What if this was all just theory that did not really work in the real-world development?

I decided to keep researching, though, and keep trying it out. During this research, I came across another incredible talk, "TDD, Where Did It All Go Wrong" by Ian Cooper.

That talk changed everything.

I finally understood what I was doing wrong. I was testing the code, not the behaviour I wanted to achieve. I was creating a highly tight coupled test of my implementation details. That’s why it felt painful. That’s why it wasn’t working.

Armed with that new perspective, I gave it another go. And this time, it was different.

I stopped trying to test everything. I focused on testing what mattered. I stopped coupling my tests to how the code was written and focused on what it should do. My tests became simpler. My code became more expressive.

And that is the reason I can say that applying TDD rightly improved my DevExp. After learning how to do it properly, I finally got the benefits everyone talked about. I started having fewer regressions, faster feedback, and having more time to do what I really like to do: build great software products.

If you are still figuring out what TDD is and if you should use it, that's ok, just keep practicing, because one day it will click, and when it does, it will be like pulling back a curtain to reveal a scene you didn't know was there.