Syllabus Lesson 79 of 141 · Bugs that lie
Bugs that lie

Symptom or cause

Why it matters A bug report shows you one wrong output. The fastest change that turns that one output right is almost never the fix. It is a patch over the symptom, and the bug is still there, waiting for the next input.

Paste a failing test into an AI assistant and ask it to make the test pass. It will. Often it does that by teaching the code about the test: an if for that page, that date, that customer. The visible case goes green, and nothing about the real fault has changed.

Symptom patch: a change that makes the reported example right without explaining why it was wrong. Tell-tale signs: a special case that names a value from the bug report, a fudge factor, or a fix in the place the error showed up rather than where it was made.

Cause fix: a change you can explain as "the code assumed X, and X is false". After it, the example passes for the same reason every other input passes.

Three questions before you patch

  • What is the smallest true sentence about why this output is wrong?
  • Which other inputs share that cause? Name two that the report did not mention.
  • Would my change still be right if the example in the report had been a different one?

In this module each problem gives you buggy code and one failing example. The hidden tests use other inputs with the same cause. A patch that only knows about the example will fail them, and the exercise always tells you what kind of inputs the hidden tests use.

One problem is a boring trap: the one-line patch really is the fix, and rewriting the code to feel safer loses.

Recap Find the false assumption, then fix it there. If your fix mentions the example, it is probably a symptom patch.

Spotted a problem in this lesson? Report it · Ask about this lesson

This exercise opens soon

Finish the lesson before it and this one unlocks. The whole course is free, no account needed, and you can read this lesson right now.

Start at lesson 1 Back to syllabus