How I stopped hating Test Driven Development
Photo by Gabriel Garcia Marengo on Unsplash

I didn’t used to enjoy TDD. I thought I understood it — I’d tell people it was a useful practice and I’d go through all the motions when demonstrating it to them; but when push came to shove I’d quietly drop it as soon as I needed to do anything taxing.

I’ve always felt some embarrassment about this, possibly even guilt. The people I admired and looked up to as developers seemed so adamant that it is the right way to write software. They commanded such respect within the organisations and communities that they worked, and I wanted to be like them; calm, confident and measured , no project too daunting.

Yet, try as I might, I just couldn’t work out what their secret was. Why did they find TDD so enjoyable? Why did I get lost every time I tried to make an honest go of it? Why did I feel like such an imposter?

I think part of the problem was the apparent simplicity of the process. You write test code before you write production code. How hard can it be? It doesn’t help that people who have mastered the practice make it look effortless. The thing is… it’s not effortless. Not to start with anyway. I think the biggest pothole on the road to TDD enlightenment is the idea that you are suddenly going to feel enlightened. Like anything TDD takes practice and experience.

We get better at things little by little, step by step. The premise behind TDD is simple, but its application is nuanced. It’s okay (and normal) for things not to be perfect when you’re just starting out. If you find yourself stuck, don’t get hung up on it. Take a break from TDD and do what you need to do to move on. Writing code that is missing a few tricky tests is much more valuable than having something unfinished that no one gets to use.

It wasn’t until I started to forgive myself for not doing perfect TDD all the time that I started to get better at it. You need to give yourself room to make mistakes and learn what’s easy, and what’s difficult. If you don’t allow yourself to do things sub-optimally and move on, it’s impossible to look back and reflect upon how you might do it differently next time.
['David Capper']
['Tdd', 'Software Testing', 'Software Development', 'Software Engineering', 'Test Driven Development']