What this tells you

Your tests are testing something other than what your app does. This is worth diagnosing rather than patching, because a suite you can't trust is worse than no suite — it gives permission to ship.

The usual reasons

Everything is mocked. The test mocks the database, the API and the queue, then asserts the mocks were called. It proves your code calls things, not that anything works.

Tests were written to pass. Especially when generated after the fact: they assert whatever the current behaviour is, including the bug. A test written from the code can only ever confirm the code.

The units work; the wiring doesn't. Every function is correct in isolation and they're connected wrongly. Unit tests never see this.

Test data isn't real data. Clean fixtures with every field populated, versus production rows with nulls, empty strings and unexpected encodings.

A different environment. Tests run with different config, a different database, or different feature flags.

The fix

Add one test at the level where it actually broke:

integration-test.txt
My unit tests pass but this broke in production: <describe what
happened>

Write one test at the level that would have caught it — a real request
through to a real (test) database, no mocks of my own code.

Then tell me:
- Which existing test SHOULD have caught this, and why it didn't.
- Is that test mocking something it shouldn't?
- What's the smallest change that makes my suite trustworthy here?

Then write the regression test

Every bug that reaches production gets a test that fails before the fix and passes after. Over time your suite becomes shaped like your app's actual weaknesses, which is worth far more than coverage.

If a test has never failed, you don't know it works. Break the code deliberately and confirm the test goes red. An assertion that can't fail is decoration.