Tech Twitter would have me believe that test-driven development is the worst thing ever. Maybe it’s just trendy to hate it, or maybe it’s a historical thing. I don’t have that context. I’m an advocate for well-tested code and I work in an environment where our tests give us a lot of confidence. I’ve also worked in a place that only did manual testing when new features were added. Those weeks of hunting down bugs weren’t fun especially when the behavior of the new features were completely intertwined with existing features. Those were definitely places where automated tests could’ve saved us hundreds of hours of blood, sweat and tears. So, why do I still think test-driven development isn’t the answer?
Before we start, let’s outline the test-driven development framework [1]:
- Read, understand, and process the feature or bug request
- Translate the requirement into a failing unit test
- Implement the code that makes that test pass with the simplest solution
- Refactor code
- Repeat
My first take to seeing this was this should be interpreted and not be regarded as a framework. It’s imperative for developers to understand the benefits of tests, even when in my experience the suggestion of writing tests causes them to shift uncomfortably in their seats. When you regard the framework loosely it encourages thinking of the testability of code when developing. Prescribing a stringent framework has put and will put people off from writing any tests in the first place. It’s important to try and understand the sentiment rather than brush it off with, “don’t knock it till you’ve tried it”. I think the reason is the framework itself isn’t congruent with the way people think through problems.
In my experience, when faced with a problem, bug or feature the response usually isn’t:
“What should I tackle next? Should I write another failing test or refactor?”
It’s often:
“Why is this happening? Will it work if I try this?”
TDD isn’t the way we encourage anyone to solve problems, let alone engineers. We encourage them to experiment, tinker and try different things. We try and foster curiosity and also critical thinking. You could argue that that is what TDD posits, but it isn’t really; not if you adopt it strictly. “Read, understand and process” sounds like critical thinking, but what does “understand” and “process” even mean? Without experimentation, you might not be able to ask the right questions in the first place to properly understand the problem. Being tied to writing a test before trying something out introduces hurdles before it facilitates problem solving.
We should definitely encourage engineers to write tests. It’s a valuable tool to document weird behaviors and edge cases, and to ensure engineers don’t accidentally refactor those considerations away. It’s a tool to introduce confidence into areas of your codebase that may inherently be more fragile. However, I don’t think it should be the primary mechanism through which we think about a problem. Even though writing tests first might encourage exploratory questions that may catch something, it’s often the case that you don’t think of all the edge cases. This isn’t a fault of TDD but this not something TDD can mitigate either [2], so why do twice the work? I think you’ll be in a good place if all you got out of TDD is “well-tested code is good”. If you’re being force-fed the TDD framework, then that by definition isn’t agile [3] because it puts process over people.
If you think of anything I have missed or just wanted to get in touch, you can reach me through a comment, via Twitter, via Mastodon or through LinkedIn.
References
- 5 Steps of test-driven development [Website]
- Difficulties in using TDD [Medium]
- Agile Manifesto [Website]
Photo by Julia Koblitz on Unsplash
Top comments (0)