FIT2109 Chap.8 Systematic Debugging
Systematic Debugging
Systematic Debugging begins by making the failure reproducible. Record the exact input, environment, command and observed result before editing code. Then locate the first boundary where actual state differs from the contract, form a hypothesis that predicts evidence, change one cause and verify in widening rings.
The mock solution identifies reproduction as the first move for an intermittent crash.
Assignment 2 reinforces that method by treating supplied tests and docstrings as accurate descriptions of required behaviour. A failing test is a clue about the implementation, not permission to weaken the specification. Higher rubric bands reward root-cause reasoning and unmodified passing tests.
What this chapter covers
- 01
Reproducible inputs, environment and trigger steps
- 02
Symptoms separated from mechanisms and root causes
- 03
The first incorrect value or state boundary
- 04
Falsifiable hypotheses that predict an observation
- 05
Focused tests as executable behaviour contracts
- 06
One controlled change rather than stacked guesses
- 07
Verification from reproduction to complete suite
- 08
A report trail from discovery through regression checks
Worked example · free
Diagnose a filter that leaks between calls
- +1Reproduce both calls in one process because separate invocations reset module state.
- +1Assert that the second call should return records from every service.
- +1Observe the filter value at function entry for both calls.
- +1Identify retained or mutable state that survives from the first invocation.
- +1Repair the function so each call derives local state from its current arguments.
- +1Add a regression test covering the filtered call followed by the unfiltered call.
- +1Run related filtering tests and then the complete suite.
- +1Explain why testing only through separate shell processes would miss the leak.
Key terms
- Reproducible case
- A controlled input, environment and sequence that reliably exposes a fault and provides a baseline for testing repairs.
- Symptom
- The visible incorrect result or failure reported by a user or test. It may occur far from the underlying cause.
- Root cause
- The violated rule or incorrect state transition that produces the symptom. Repairing it prevents recurrence rather than hiding output.
- Hypothesis
- A proposed mechanism that predicts a specific observation. Evidence can support or refute it before a code change is made.
- Regression test
- A check that fails under the old faulty behaviour and protects the repaired contract against later reintroduction.
- Verification ring
- A widening sequence from the original reproduction through related checks, complete suite and delivery environment.
- State leak
- Data from one operation incorrectly influencing a later operation that should begin from independent state.
Systematic Debugging FAQ
What should I do first with an intermittent failure?
Record the input, environment and exact trigger steps, then reduce the case while preserving the failure. Without a reproducible baseline, you cannot know whether an edit repaired or merely obscured the problem.
Why is broad exception handling often a weak fix?
It can hide the visible crash while leaving corrupt state or wrong output. Diagnose the rule that was violated, handle only expected conditions and preserve useful diagnostics for unexpected failures.
How do tests help locate a root cause?
A focused test states an input-output contract and reports actual values. Read the assertion, trace the earliest divergence and use that boundary to compare hypotheses rather than changing whichever function looks suspicious.
When is a repair fully verified?
The original reproduction passes, related behaviour remains correct, the full suite is green and the delivered environment exercises the repaired path. Review the final diff to ensure no test or assertion was weakened.
Assessment move
Use a repeatable five-column notebook: symptom, exact reproduction, first incorrect state, hypothesis and verification. Take a small program and introduce one defect at a time. Before editing, preserve the failing input and predict the intermediate value that would confirm your hypothesis. Choose a debugger, temporary observation, focused test or manual comparison according to the question you need to answer.
Apply one change, rerun the reproduction, expand to related tests and then run the complete suite. Remove temporary instrumentation but retain a regression test. Practise explaining a rejected hypothesis as carefully as a confirmed one.
For Assignment 2 preparation, write each defect as a compact row containing what the code did wrong, how the fault was found, the root-cause repair and how correctness was established locally and in the container. This produces the evidence the rubric rewards. Recreate one repaired fault on the parent commit and repeat the same command after applying the fix.
This verifies that the behavioural change, rather than unrelated environment drift, explains the new result. Add one counterexample that should remain valid and one malformed input that should still fail safely. Together they test both the repaired rule and its boundary.
Working through Systematic Debugging in FIT2109? Sia is AskSia’s AI Computer Science tutor — ask any FIT2109 Systematic Debugging question and get a clear, step-by-step explanation grounded in how FIT2109 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
