Your Codebase Has No Tests: Why Your Developer Is Scared to Change Anything

You just switched development teams. Things weren’t quite right with the old agency. Nothing you could put your finger on, just a feeling. Slow responses, changes that took longer than expected, a general sense that momentum had stalled.

The new team does a health check before they start work. Standard practice. A week later they come back with something you weren’t expecting: your app has been generating errors in the background. Quietly. For a while. And the reason, they tell you, is that large parts of the codebase have no automated tests.

You thought everything was being tested. You’ve been signing off on releases for two years.

How do you know if you’re in this situation?

The signs are usually in how your team talks about changes. “We’ll need to test everything manually before we release that.” “Can we schedule that for a quiet week?” “That one’s risky. It touches a lot of things.” These aren’t unreasonable things to say, but if you hear them constantly, it’s worth asking why.

What automated tests actually are

Automated tests are code that checks other code. When a developer makes a change, the tests run automatically and confirm that everything still works the way it’s supposed to. If something breaks, the tests catch it before it reaches your users.

A quick example Say your app has a feature that lets users sort books A to Z. It’s been broken for months. Not occasionally, consistently. But nobody reported it, and nobody on your team knew, because there was nothing watching for it. You only found out when someone looked at the logs. That’s what no tests looks like in practice: not a dramatic failure, just silent errors accumulating in the background while everyone assumes things are fine.

Tests don’t care about layout. They don’t check whether a button is blue or whether the header is 24px. They test behaviour: what happens when you do something. A simple static page might have two or three tests. A page with sorting, filtering, pagination, and logged-in versus logged-out states might have 30 or 40. The more decisions a page makes, the more tests it needs.

Most codebases don’t start without tests by design. They get skipped early when everyone’s moving fast and deadlines are tight. The intention is always to add them later. Later rarely comes.

Why your developer goes quiet when you ask for a “small change”

Think of an untested codebase like a Jenga tower that’s been played for a while. Every piece is load-bearing in ways that aren’t obvious from the outside. Pulling one block might be fine. It might bring the whole thing down. The only way to find out is to try.

Your developer knows this. When you ask for what sounds like a simple change, they’re mentally mapping every piece it might touch. The hesitation isn’t incompetence. It’s the rational response to working without a safety net. This hesitation compounds fast in when an app was built fast with AI, where speed of building often came at the direct expense of this kind of safety net.

This is also why estimates feel unpredictable. A single two-hour change becomes six additional changes because something unexpected broke downstream and no one knew it was connected.

What it’s costing you

Slow releases are the obvious one. But the compounding costs are worse.

Errors your users hit that you never knew about, because there was nothing watching for them. Good developers who leave because working in an untested codebase is stressful and professionally embarrassing. And a growing reluctance to touch anything, which means the features you actually want keep getting pushed down the list in favour of “stability.”

The longer it goes without tests, the more expensive it gets to add them. The codebase grows, the dependencies tangle, and the gap between where you are and where you need to be gets wider every quarter.

One thing to do this week

Ask your developer for a coverage report.

Most modern development frameworks can generate one in minutes. It shows, as a percentage, how much of your codebase is covered by automated tests. There’s no universal benchmark for what “good” looks like. It depends on the app. But the number itself is less important than the conversation it starts.

100% coverage isn’t the goal. What matters is that the right code is covered:

• Code that changes often (high risk of regression)
• Code that’s complex (easy to break accidentally)
• Code that’s critical (checkout, payments, core user flows)

Chasing 100% wastes time on code that rarely changes and almost never breaks.

If your developer can’t produce one, or isn’t sure what you’re asking for, that’s useful information too.

If you want to know where your app stands, we offer a straightforward technical health check that gives you a plain-English picture of your test coverage and the other things that affect how safely and quickly changes get made. No jargon, no developer required to interpret the results. Get in touch.