A program that finishes has told you it finished, and nothing else. Meet the three kinds of wrong, then find a real bug that only one number in the world can reveal.
A program that finishes without complaining has told you exactly one thing: it finished. Whether the answer was right is a completely separate question, and only you can answer it.
Your course description names “design, develop and test/debug” as the skills it builds, and asks for programs that are “correct and maintainable”. Correct is not the same as running. Almost all of the marks — and all of the real-world consequences — live in that gap.
Here is a tiny program that decides whether someone can vote. It has a bug. It is not hidden and there is no trickery — but you will only see it if you feed it the right number.
Try some ages. Watch the coverage strip fill in underneath.
| age | it said | should be | |
|---|---|---|---|
| no tests run yet | |||
25 works. 40 works. 10 works. 3 works. You could test a hundred ages, feel thorough, and never find it — because the only value that exposes this bug is 18 itself. Testing the middle of a range tells you almost nothing. The interesting values are always at the edges.
You do not need many tests. You need the right ones. For any rule with a boundary, there are exactly three places worth looking, and you can work them out before writing a line:
Just below the line (17), exactly on it (18), and just above (19). If those three are right, the whole range is almost certainly right. If a bug exists, it is nearly always sitting on one of those three — and by far the most often, on the exact boundary.
Then add the ones that are strange rather than wrong: zero, nothing at all (an empty list, a blank answer), and something absurd (a negative age, a name where a number should be). Those three catch most of what remains.
This is not extra work bolted on at the end. Working out what the answer should be, before you run it, is the only way you can ever tell whether what came back was right. If you do not know the expected answer, you are not testing — you are just watching.
When a test fails, the instinct is to reread the code and hope. That almost never works, because you read what you meant — the level 4 problem again.
Do this instead, in order. Find the smallest input that still fails. A bug that shows up on one number is a hundred times easier than one that shows up on a list of forty. Then trace it by hand and find the first row where the numbers surprise you. Then fix that — and re-run the test that caught it, plus the ones that passed before, because fixing one thing breaking another is entirely normal and is exactly why you keep the old tests.
The computer is not doing something random. It is doing precisely what it was told, every time, in order. Whenever a program seems to behave impossibly, the impossible part is always an assumption of yours — and tracing is how you find which one.
Write a rule with a number in it. “Under-16s get in free.” “Free delivery over £30.” Then say what should happen for each value B throws at you — before B says what they think.
Attack the edges. Exactly 16. Exactly £30. Zero. Minus one. A person with no age recorded. Someone who is 15 years and 364 days.
Person A committing to the expected answer first is the whole exercise — that is the difference between testing and watching. You will find that most arguments are not about the code at all. They are about what the rule was supposed to mean, and finding that out before you build is worth more than any amount of debugging afterwards.
The dangerous bug is the one that finishes cleanly and hands you a wrong answer.
Just below, exactly on, just above. The middle of the range almost never finds anything.
Decide the right answer first. Without that you are watching output, not testing.
Not recall — these are the shapes an exam actually uses. Every answer below was produced by compiling and running the code, so if you disagree with one, the compiler is the one to believe.
Have a real go before revealing. Being wrong here is worth more than being right in three weeks.
Which kind of error is the dangerous one?
A rule is “18 or over can vote”. Which single test value is most likely to expose a bug?
You run your program, it prints an answer, and nothing errors. What have you learned?
← back to all 12 levels · stuck on anything? ask peter.