Unit Test

via GIPHY

This is just a fact of development. If you are not unit testing your code, you are saying you are perfect and never make mistakes. I hate to be the bearer of bad news, but this simply is not true for anyone. Unit tests are derived from the FACT that the sooner you detect a problem, the cheaper it is to fix. This is because of the huge turn around time it takes for a bug to be fixed.

Here is the typical lifecycle of a defect:

• Your quality assurance team or, even worse, a customer finds the bug.
• They have to then report it.
• Steps of reproduction must be created.
• It must then be prioritized by the product team.
• Designers and developers must then come in and assess possible solutions.
• A defect is then created.
• Someone is assigned to work the bug.
• They then fix it and resubmit back to QA.
• Repeat

Unit tests are not a corner that is acceptable to cut if there is to be longevity to the project. Yet so many teams look to them as the first thing to drop because they “take a long time”. Well, fixing a bug takes even longer and therefore costs much more money.

Unit tests allow the developers to have fearless change in the code base knowing they haven’t broken anything in the application based on what they have altered. The tests also provide instant feedback on where the problem is and guide developers to fixes. Beyond that, they create living documentation that explains how the code works.

For these reasons, unit tests provide huge benefits to code quality. Increasing code quality is the fastest, most efficient way to reduce cost. At a previous company, we had to change the business logic of a feature to be compliant with some new government regulations. The area of code had been created by a developer that was no longer part of the company. He/she had architected the feature alone, without any unit tests. Rather than rearchitecting the code, which probably would have been faster and more useful in my opinion, management decided that they should make changes to the existing code, and revisit rearchitecture later.

We began seeing huge increases in defects, but only around this area of the application, even while changing and modifying many other sections of the app. Every single time something was fixed, more defects would arise. This continued for months as the team just fixed and fixed until they had no more time left. I have never had a better example to support unit testing. Side by side, with the same team of developers, the code that wasn’t unit tested was taking longer to change and fix than any code that did have unit testing. The defect lifecycle repeated until we had to leave defects in the app. We simply didn’t have any more time due to a deadline outside of the company.

Customers began calling in expressing their disappointment, and management was not happy with so many defects and the poor quality of the app. Notice it wasn’t specifically with that section they were pointing out, they were saying the entire application. It was being recognized by the poorest part of the entire thing. Imagine being the developer on the project. You work really hard and are proud of a lot of the application, and are being labeled by this one part that doesn’t even conform to anyone’s ideals of standard anymore.

I want to thank you for taking the time of out of your busy day to read this. I really hope you take this information and utilize it. Who knows, maybe one day we will work together and you will be one of the projects I am impressed by.

The real solution to solving a project’s problem and saving money for a company, long term, is really to increase quality. Yes this is going to take more time, yes this is going to cost more up front, and yes your company will love it. When everyone is focused on improving quality, they will really love their job and take a lot of pride in it. The defect rates will be nearly non-existent and your team will be outputting new quality features faster than they can be designed.