Skip to main content
Handbook/Test/Chapter 76 · Trust

Do the Tests Actually Test?

Share

Share this page

Pass it to someone who needs it.

Key takeaway: Green tests can still test nothing

Your suite is green, so you feel safe. But a test can pass while checking nothing at all, and the agent that wrote your code also wrote your tests, with the same blind spots baked into both. A green suite you cannot trust is worse than no suite, because it tells you to stop looking. This chapter gets you a way to tell a real safety net from a green light that means nothing.

8.7.1A passing test can check nothing

A test passes when nothing in it fails. That sounds obvious until you see the trap: a test that checks nothing also has nothing to fail, so it passes forever.

Green is only as good as the check inside the test. A test that runs your code but never asserts the result is a green light wired to nothing. It will stay green while the feature underneath rots.

8.7.2Coverage counts lines, not correctness

Coverage is the percent of your code that your tests actually run. Tools like Vitest coverage report it, and it is genuinely useful for one thing: finding code no test touches at all.

But high coverage is not proof of correctness. Running a line is not the same as checking what it produced. This test hits every line of applyDiscount and asserts nothing that matters:

test("applyDiscount runs", () => { applyDiscount(100, 0.2); // 100% covered expect(true).toBe(true); // checks nothing real });

That is 100 percent coverage on a test that would stay green if applyDiscount returned garbage.

8.7.3Watch for tests that can't fail

A worthless test is one that cannot turn red no matter how broken the code gets. Three smells give them away:

  1. No real assertion: it runs your code but never checks the output, or only asserts something trivially true like expect(true).toBe(true).
  2. Over-mocked: so much of the real code is faked that the test only checks the mock you wrote, not your actual logic.
  3. Mirror test: it restates the implementation instead of the expected result, so it agrees with any bug the code already has.

8.7.4Break the code on purpose

The fastest way to trust a test is to make it fail on purpose. Change the code it guards to something wrong, rerun, and watch for red.

If the test turns red, it was really checking that behavior. If everything stays green after you broke the code, those tests were never testing anything.

Break the code, rerun; red means the test was real, green means it was never testing.

You do not do this by hand. Hand the check to your agent, which can break each piece, rerun, and report which tests actually caught it:

Ready prompt
Act as a senior engineer auditing my test suite for tests that pass without testing anything. Find and flag three failure modes: tests with no real assertion, tests so heavily mocked they only check the mock, and tests that mirror the implementation so they can never catch a bug. Report coverage honestly: separate code no test runs from code that runs but whose result is never checked. Then prove the important tests work by breaking the code they guard, one piece at a time, rerunning, and listing which tests turned red and which stayed green when they should not have. My suite and what it should protect:

Do this now: paste the prompt, then pick your most important test and break the code under it by hand to confirm it turns red.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

Resources
Contribute
Donate

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish.
Copyright & license