Key vocabulary

Locating faults with debugging techniques

From "it failed" to "here's why"

SDD16's test plan can only tell you that a test case failed — a pass/fail result on its own says nothing about where in the program's logic the fault actually lies. Debugging picks up exactly where testing leaves off: once a failing test case has been identified, these four techniques help locate the precise point where a program's actual behaviour starts to diverge from what was expected.

Dry runs and trace tables

A dry run means manually working through code step by step, by hand, exactly as the computer would — without actually running it. A trace table is the tool used to do this systematically: a table with one column per relevant variable, and one row per step (usually one row per loop iteration), recording every variable's value as it changes. Dry runs and trace tables were already used informally in SDD13/14's worked examples — SDD17 formalises this as a deliberate debugging technique, used specifically to find the exact iteration where a program's actual values first diverge from the expected ones.

Breakpoints

A breakpoint is a marker placed on a specific line of code within an IDE (such as PyCharm). When the program runs, execution pauses automatically the moment that line is about to be executed, allowing the programmer to inspect every variable's current value at that exact point before choosing to continue. Breakpoints are ideal when the programmer already has a good idea of which line is worth stopping at.

Watchpoints

A watchpoint is different, and is frequently confused with a breakpoint: rather than being tied to a specific line, a true data watchpoint is tied to a specific variable, and pauses execution whenever that variable's value changes (or meets some condition), no matter which line of code causes the change. Watchpoints are especially useful when the programmer knows which variable is behaving unexpectedly, but doesn't yet know which line is responsible. This is a generic debugger concept, not a promise that every IDE implements it. In base PyCharm, a Watch is an expression whose value is displayed after execution has already paused at a breakpoint; it does not itself suspend the program when a Python variable changes. A Watch expression plus line or conditional breakpoint can approximate the investigation, but it is not the same as a true data watchpoint.

Worked examples

def linearSearchBuggy(array, target):
    index = 0
    found = False
    while index < len(array) - 1 and not found:
        if array[index] == target:
            found = True
        else:
            index = index + 1
    if found:
        return index
    else:
        return -1

itemNames = ["Chocolate", "Crisps", "Juice", "Flapjack", "Sweets", "Muffin"]
result = linearSearchBuggy(itemNames, "Muffin")

Task Set A — Core questions

Task Set B — Extension