How Does TDD Really Work? (Pt 3)
Real world Test Driven Development
How many web tutorials have you watched where someone builds a simple todo list?
How many simple todo lists have you been asked to build for money? Not many? No, me neither.
To work!
I’ve been doing Test Driven Development over the past 6 months, and it’s finally beginning to pay off.
The first few months at my current job I was getting possibly 1 to 2 urgent bug-fix requests per day. This went on for about three months. It was possibly the hardest period of my career to date, extremely stressful and worst of all, political.
Imagine a situation where you’re hired in as a company’s only developer, they’ve previously worked with a single dev through a respectable agency who they trust and he knows the system inside-out.
Now he’s gone, they’ve had you for three months and suddenly the bugs and customer complaints start streaming in!
I’m like…
So what happened?
Have you ever finished working on a feature, then merged the work and gotten a bug report later on, relating to that feature? I expect about 50% of the time, you find that bug easily and fix it within a matter of an hour or so. Another 40% of the time you know where to look and can quickly estimate what the problem is.
Let’s say you’ve been working on a project for a number of years, the project becomes your home, you know where everything is, you know which bits of the code base need refactoring, you might even have prioritised those parts in your head and are working on them in a specific order.
None of this is written down. You know that, even if it was written down, it’s likely to be abandoned by any future developers, and in any case it tends to move and shift as you go on, making it unhelpful to solidify the plan by writing it down anyway.
A new developer joins your company and you have about two months to hand over the project to him. But you also have some jobs to complete yourself so the time spent with the new developer is limited.
Well, you know where I’m going with this.
Hand overs are difficult
The extra catch on this application is that it has dips and peaks over the course of the year in traffic. Every three months the app gets a huge peak of activity over the course of a week when new products are added to the platform.
So what happened was, a ton of new features where written by the old developer, this work was only manually tested by him, two months later we had a peak in activity, and a ton of bugs surfaced from those features. This happened just as the old developer had finished and left the company.
Ideally we would have addressed those bugs together, unfortunately this delay in feedback from the user-base meant that I had to fix them without him which was much more slow going.
Good time to start TDD for the first time?
Maybe not, but I did it anyway.
Fast-forward to now. I’m getting, possibly, one urgent bug-fix request every two weeks, if that.
This isn’t the whole story of course. I did add my own bugs and I caused many regressions; bugs that resurfaced from some change I’d made fixing or building something else. This is a huge reason I decided on TDD, it allowed me to make consistent progress. If I build a test for a bug, I know that bug won’t come back because it’s being tested for.
I was reminded recently by another dev, how much value is being added to my application by writing tests for it. Stable and maintainable applications are incredibly valuable, one reason for that is they allow for easier handovers. The application is less reliant now, on my own internal plan, less reliant on a single developer’s mind.
I’m actively making myself more replaceable. Am I now more likely to lose my job? Well, not likely. I think that’s the wrong way to look at it.
I want the company to benefit from my time, I don’t want them to be stuck with me. Also this allows me to move to different areas of the application — devops for example — learn new skills, and hire new developers who can get stuck in.
Now I can do all of that without having to worry about regressions but also I can provably say that we’re making progress with the stability of the application.
Trackable progress
I had a recent bug report from someone in the company. They said, this bug was a regression because they’d reported it before. I checked our past tickets and found that they had reported this bug, had a look at my tests and found that the problem had been fixed already. It turns out the person was reporting a different bug but it looked similar in the UI.
This is just one example of how difficult it can be to tell if you’re making progress or not and it becomes more difficult as your team scales and again more difficult if members swap or leave.
I can now ask my tests, am I fixing a new bug or am I fixing the same bug again? In the long run this more than makes up for the extra time spent working on features and bug-fixes.
Trackable features
A huge problem I faced early on at this job was that I didn’t know the features of the app. There’s been so many features built over the years that I couldn’t possibly know them or even know if I was breaking one accidentally.
So, when a new bug request comes in I start by writing a test to replicate the bug, then I fix it. The test then becomes a way to track that fix. It proves the fix happened and if the fix gets unmade at any point, the test will break and we’ll know about it.
No documentation needed, no need for helpful comments, no need to even tell anyone. The test does all those things and more.
