Tests are for Future Releases

I used to think of tests as just a final check to confirm whether a feature worked. That perspective shifted a few years ago when I had shipped a feature, and later a teammate made changes that unintentionally broke a small but important part of it. No one noticed during code reviews or QA, but a simple code comment I had left — reminding myself to manually test an edge case — caught the issue.

It made me realise that tests aren’t just about verifying today’s work; they’re about safeguarding tomorrow’s. Whether it’s me revisiting the code months later or someone else making changes, tests act as a safety net, ensuring the feature continues to work as intended.

So when I joined my current organisation, one of the first things I proposed to the mobile team, was introducing tests. We have four mobile applications: two internal and two consumer-facing apps. One consumer-facing app that I work on is hybrid (Flutter + native Android and iOS) and has a team of 7-10 people.
Being a startup, we’re always chasing the next release, sprint, or metric. This often means shifting people between features. Breaking your own code is one thing; breaking someone else’s is almost guaranteed in this environment.

Given our user base and the need for stability, tests made sense. Everyone agreed, so I started a POC.
I picked a small Flutter module with two screens and built an internal framework using flutter_test. For the POC, I wrote two unit tests and one integration test that covered 4–5 edge-case flows. This meant setting up mocks for APIs, local storage, and analytics, setting up flavors, dependency injection tweaks, and documentation.

Then I showed this to the mobile engineering team.

To set the company’s mindset (since tests are considered heavy resource investment), I wrote separate documentation on test coverage. I suggested starting with tests for highly bug-prone code. Later if time permitted, we could add tests for business-critical features. The goal wasn’t 100% coverage, it was achieving the stability and saving time on bug fixes in future iterations.

The team’s initial response was hesitant, but it highlighted the challenge of balancing resources and stability in a startup.

It was a little discouraging, but I continue to suggest tests whenever a production bug occurs.
I think in this fast-moving startup, tests should not be treated as a luxury, an afterthought. Even a handful of tests for critical use cases can save us when teammates switch, features evolve, or releases get rushed.

Tests are for Future Releases

Comments

Software Craftsmanship

How “Design Patterns Explained” Changed the Way I Design Software

More from this blog

How “Design Patterns Explained” Changed the Way I Design Software

I Don’t Know Machine Learning as Well as I Thought I Did

When AI Suddenly Took Center Stage

Navigating the Waters of Technical Curiosity: A Confession

Command Palette

Comments

Software Craftsmanship

How “Design Patterns Explained” Changed the Way I Design Software

More from this blog