There's a Catch-22 hidden in the arguments that many people use to rationalize not writing tests.
The Catch
A Catch-22 is a situation that you can't escape out of due to contradictory rules or limitations. In case of automated tests for software, the arguments often go like this.
At the start of the project, both developers and managers say that the project is too young and changing all the time. There's also market pressure to get something minimal out there as fast as possible. So there's no time to write tests.
But once the project has matured, the code is harder to put under test, the developers haven't adopted the necessary habits to write tests, and surprise surprise, the market pressure is still there.
So no tests are ever written. Unfortunately, this leads to increasingly complex and highly coupled code that is increasingly harder to test. Progress slows down and frustration follows.
Escaping the Negative Cycle
So when should we start writing tests? When people ask me that question, the answer is usually now. Right now.
If your project is only getting started, it can be OK to write some code without tests: a proof-of-concept, a very small MVP to see if it works, etc. Just to see if and how things would work out.
But this period is shorter than most would expect. In 2-3 weeks, a team of average skill can get something up an running and then they should start taking things seriously. This includes writing tests.
An experienced team (with TDD experience) will be able to write code that can be tested afterwards with minimal effort. But even they should not allow that “test-less” time to take too long. Inevitably, code will become coupled and difficult to test.
But I'm Not Allowed!
What if management or some lead dev/architect forbids you from writing tests?
My advice? Still do it.
First, management shouldn't be telling you how to write code, only what to implement. Lead developers and architects are different, but they wouldn't tell you which keyboard layout or IDE to use, would they? Testing can be seen as a tool to write code. Instead of running the application to verify your changes, you can say you run automated tests.
You can then also explain why this works faster for you. There is less manual testing and debugging to be done. It also leads to better code quality and stops other developers from breaking features you've implemented.
But of course, that assumes there is room for rational arguments. If there isn't, do you really want to work there? With companies screaming desperately for developers, you should be able to find a better place to work. There's a reason there are so many recruiters in the IT industry.
Of course, this might be different in your specific situation or region, but in general, there are better jobs out there for developers.
Start Now
So regardless of how old your project is and regardless of what others tell you, my advice is to start writing tests now.
If you have a legacy project and don't know where to start, try to find a small piece of code that is isolated and write a test for that. It'll allow you to set up the necessary CI infrastructure giving you the foundations to continue.
Once you start writing tests, you'll get better at it and start noticing other places where you can add tests.
Often, it just takes a small push to get others to start writing tests as well. A simple first test written by one developer often leads to more and more tests written by the entire team.
Top comments (0)