The Cost of “Doing it Later”

“I'll add tests later” or “I'll add tests in the next pull request”? Have you ever been hit with this in a code review?

But will it get done right away? Will all the necessary test cases be remembered? Will they be kind to ping you when they have added them?

The truth is many scenarios can happen between now and that time:

New, critical or high-priority requests
Go on vacation
Maternity leave
Forget to do them
Get sick
Injury
A loved one dies / bereavement
Change teams
Team dissolves
Change companies
Die

We can try to squeeze missed tests into a PR shortly after, the next sprint or handle them as tech debt items, but the truth is that life is unpredictable and can throw us curveballs. We have to acknowledge that the opportunity to right things may never come.

It happens more than you think.

Whenever I'm hit with a “I'll do it later”, it irks me a bit because I've seen many occurrences where doing it later never ends up happening. When it comes to testing, we leave ourselves vulnerable if we decide to postpone them.

Write tests now

We know why it's important to write tests, but why is it important to write them right now:

Code quality assurance

I can sleep confidently knowing that to the best of my abilities I've left my code in the current state well tested.
I don't have to worry about another person coming in and breaking things between now and when tests will be added. What if a code change on top of ours introduces a regression, and it all makes it into production?
I can avoid something being sent back because a tester or a stakeholder says it doesn't work as expected. Sometimes, things work while we're working away, and by the time it gets to QA or customers, it's broken; it happens.

Self-documenting—Tests help document the behaviour and expectations of how the application is supposed to work. What better time to document than right now? Depending on how long those tests are missing, we put the next person in a vulnerable spot if tests aren't added in reasonable time. How are they expected to know about a certain code's functionality?

When tests are missing for a considerable amount of time:

How helpful is git blame for something that has changed many times, moved files, and had many updates? What will this exactly help with?
Are you going to dig through many years of tracked issues to determine what the expectations were at that time? What if the ticket was poorly documented? What if that code changed multiple times since the initial ticket? What if some changes weren't tracked? What if those people who know are no longer with the company?

Source control systems can change, and issue trackers can be substituted for a different tool. Tests live permanently with the code base; no matter what, we can expect them to live with the code forever. So when I have this in my tests:

When I do this, I expect this to happen

I know how the code is expected to function today. Tests will only go away when they are no longer needed or will get updated when functionality changes.

If you believe that your source control, or issue tracker changing is unlikely to happen, I'm sure plenty of people before you thought the same thing.

Team confidence - As a code reviewer, I have the reassurance the author has done their due diligence in fixing this bug or adding this feature within the PR if it has provided adequate testing.
Team morale - It can be worrying to work on a code base that has shaky legs, or one you can visually witness slowly becoming more brittle due to testing coverage/quality suffering.
Maintenance - As a code base evolves and becomes more complex, testing keeps us in line. How can anyone confidently refactor complex pieces without proper testing? Refactoring code that's existed without tests for years could result in a high chance of introducing bugs.

Don't fall for the trap

Next time you hear someone say, “I'll add it in the next pull request”, take a second to think what the ramifications are of not doing it EVER:

Is this piece of code crucial to our business operations?
How complicated is this for someone without prior knowledge to understand?
Could we refactor this safely in the current state?

Don't become a victim to code review peer pressure. Rushing things in is usually a recipe for disaster. People do make mistakes. By circumventing standards that the team has all agreed upon, and giving your stamp of approval, you have now become an accomplice in this gap in testing.

Imagine a factory setting where you have agreed to help someone lower safety standards just for a few minutes, and people get injured as a result. I know it's an extreme comparison, and maybe no one is dying because the HTML button is not clickable, but it take two seconds to ask yourself what the potential cost is if we don't add tests.

I'm also not saying people should be held responsible when bugs arise due to a lack of testing, but we all take some responsibility in ensuring that we collectively do things correctly for the greater good of the project/team/organization and try not to cut corners.

There may be scenarios where you have to break the rule. For example, production has an issue, and we're losing millions by the minute. That might be a time where as a team you have agreed to hotfix something without adding a test.

So what can we do as follow-up in those scenarios:

Create a follow-up issue that lists every test that wasn't done and where it should go, linking back to the original task/PR. Always remember you might not be the person to do it (remember the scenario list above), so be as clear and concise as possible so that any person understands the testing that is needed.
Monitor the progress. Whether that person is the person who approved it or the team, there needs to be reassurance that it is followed through with.
Resolve it in a timely manner. Just because the task exists doesn't mean it's fine to sit at the bottom of the backlog for a year. Let your manager know the importance of getting it resolved and the potential issues if it isn't.

Conclusion

Try to add tests for your changes within the pull request. Not only is it easier, but it's better for the team, and it's the right thing to do.

If you need to postpone adding tests, consider implementing a follow-through plan to ensure they're properly handled.