Last week I published my very first video course titled Writing Maintainable Unit Tests. It surely has been a very learnful experience. Going through the process of creating the content, recording and editing the videos was definitely quite challenging. But why a video course specifically about writing unit tests?
Well, for starters, everything related to Test-Driven Development is something that is near and dear to my heart. I think that shouldn’t come as a big surprise to anyone who knows me personally.
Secondly, I hear more and more developers complain about unit tests these days. I find this trend to be both quite interesting as well as disturbing. I find it interesting in the sense that I want to learn more about what specifically bothers these developers about their unit tests. At the same time it disturbs me as our industry definitely needs more software developers writing unit tests instead of less.
About two years ago, I attended a well known developer conference. One of the talks was about refactoring legacy code. Not an unusual topic you might say. Indeed, tech people have been debating this topic at developer conferences for almost two decades now. Being the most interesting topic for that time slot, I decided to take a seat amidst the listening audience. About fifteen minutes into the talk, the speaker starts ranting against writing unit tests.
I still think it’s kind of strange to start a plea against unit tests during a talk about refactoring code. But anyway, in this person’s point of view, unit tests are a waste of time and valuable resources. The argument was that unit tests break all the time if and when someone decides to change or refactor some code. Accordingly, the solution was to just stop writing unit tests. They were causing a lot of pain. At this point, a human tendency tends to kick in. Instead of improving on the cause of the issue, the most common solution is to just get rid of the messenger. If that would be any kind of useful solution, we might as well stop writing code altogether. I guess that would save the end-users of the systems that we build a lot of grief. Obviously, we’re not having any of that.
Anyway, now comes the most interesting part. Instead of writing unit tests, the speaker highly recommended to only write sociable tests (aka functional tests) instead. The most important reason cited was that they don’t break as often as unit tests. Bam!
After I picked up my jaw from the floor, I decided then and there to create a course for other software developers on how to write maintainable unit tests. Nobody would argue that a well-designed software system is a pleasure to work with. The same goes for the unit tests that we write. Unit test code should meet the same quality standards as the production code that it consumes. When unit tests start causing grief, then either the design of the production code or their own design isn’t that optimal.
My course is all about facing such design issues head-on when they pop up instead of shying away from them. In a previous blog post, I already argued that we should listen to the vital signs of TDD.It is at these moments that unit tests try to teach us something. The only thing that we need to do is be willing to learn.