We all know the “no time for tests” death spiral.
First we take exceptional shortcuts to ship something because “we have to ship it now but we’ll do better next time”. Of course next time we have even less time, we have to add features, we can’t really fix the shortcuts. It takes longer and longer to add features because of the shortcuts we took and cant’ remove. We start to invest a lot into fixing bugs.
That’s the beginning of a painful road for the team in charge, and we all know the end is bad. Some will try to work overtime to manage the mess. Some will burnout, tired of being so unproductive. In this hard time we’ll hear things like: “It has always been done this way, I know it’s wrong, but what can I do, I’m just a developer…”
No need to say I don’t agree, and here is the path I take as a developer every time I face this situation.
Step 1: Fix known bugs with unit tests
To introduce a quality culture in any company, start by adding unit tests every time a bug is identified outside of the development team (by the quality analysis team or in production).
When we talk about unit testing, people usually ask if it’s worth it. What’s the return on investment? How do you know what to test?
If a bug goes out of our team, we can’t afford to let it happen again. It worth it because a regression shows we are not mastering what we are building, and is really annoying for users. We know what to test because we have an exact failing use case.
Use this opportunity to introduce a build server, we want to know before shipping if we have regression.
Step 2: the tester strikes back with test first
Most people arguing against unit tests have this experience:
1> They write some unit tests
2> It is incredibly painful
3> They stop testing with the conclusion that unit tests are incredibly painful
(The official explanation is most likely: “It takes too much time to write tests”)
Truth is: writing good code is incredibly hard, writing bad code is freaking easy.
Testing our software do nothing but reveals the nature of our code. It reveals how it behaves when we try to use it. When the code is hard to test, the code is bad, that’s what we need to accept to overcome this step. No need to blame the tools or the methods. What we need is to learn how to improve the code in terms of decoupling and maintainability.
When it comes to an important piece of code, write the test first. It will lead to more testable code, because nobody likes painful things.
Step 3: Test Driven Development as a rule of thumb
After a few months, if we do not observe any improvement, it is interesting to understand why? In my experience, it may be due to a lack of experience with unit tests (tools and/or methods) and/or a lack of discipline.
But if we observe an improvement due to step 1 and 2, it’s easy to argue that to improve even more, we should not ship any use case not covered by unit tests.
The good news is that our industry already uses an efficient method for that. It’s called Test Driven Development, and we can find tons of documentation online about it.
Step 4: Less stress and better work
Be disciplined, don’t give up on TDD, and within a few months the results will be clear. The team will feel more confident and less stressed. With less stress, fewer bugs will be shipped, and we’ll have more time to improve, and to drink beers.
No overtime required. Only good habits, discipline and continuous improvement around good practices.
It is important to communicate at this stage. It may take several years to reach such a result. We should remember where we come from, what we did to improve and share our story with other teams.
It’s even better when we’re not alone
Some help by someone who already took a similar path is gold, because she will point out what’s wrong in the code and how to improve it.
She will also be familiar with tools and can avoid silly mistakes we all do when discovering these practices.
She mights also know how to manage tricky managerial issues.
It is with this kind of expertise that such a path can be achieved in a few months, instead of a few years.
That’s what a developer can do
This path is not a myth, this path is not a theory.
This path I followed 3 times already, and every single time it helps me to gain confidence, credibility and to be proud of my work.
That’s the kind of things we can do, as developers, to change the way it has always been done.
Many Thanks Nelson Da Costa for the review.
Hi Emilien.
Good practice ! This is the right approach : proof and progressiveness are change keys.