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.