Testing & Debugging

Testing is checking whether a program produces the expected output. Debugging is finding and fixing the cause when it does not. These are two different activities, and skilled developers do both deliberately rather than by luck.

This topic, part of Big Idea 1: Creative Development, teaches you to design test cases, compare expected versus actual output, and reason carefully about errors, especially the sneaky ones hiding at boundaries.

The testing and debugging cycle works like this: you write a test case (an input plus its expected output), run the program, and compare expected versus actual results. If they differ, you locate the error, fix it, and retest, including retesting things that worked before.

Errors generally fall into three families:

• Syntax errors: the code breaks the rules of the language, so it will not run.
• Runtime errors: the program crashes while running (for example, dividing by zero).
• Logic errors: the program runs fine but produces the wrong result. These are the hardest to find.

Edge cases and boundary values deserve special attention. Many bugs only appear at the exact limits of valid input. A trace table, which tracks variable values step by step, is a powerful tool for locating logic errors.

Visual Debugging Cycle

Add supporting image in static folder

The cycle: Write test case → Run program → Compare expected vs actual → Locate error → Fix → Retest.

Notice that the arrow returns to the start. After a fix, you test again, because fixing one bug can reveal or even create another. On the exam, correct answers treat debugging as this repeating cycle rather than a one-time event, and they emphasize comparing expected with actual output.

• Test case: a specific input paired with the output you expect.
• Expected output: what a correct program should produce for a given input.
• Actual output: what the program really produces when you run it.
• Edge case: an input at the extreme or unusual end of what is allowed.
• Boundary value: an input exactly at a decision threshold (like a cutoff score).
• Trace table: a chart tracking how variables change as the program runs, step by step.

Be ready to:

• Classify an error as syntax, runtime, or logic.
• Trace a code segment and predict its output for a given input.
• Choose a test case that would expose a specific bug, often a boundary value.
• Explain why testing only "normal" inputs is insufficient.

The Create Performance Task requires describing the testing you did. Identifying boundary cases is one of the most reliable ways to write convincing, specific test descriptions.

Consider this grade logic, which is supposed to assign letter grades:

IF(score > 90)
{
    grade ← "A"
}
ELSE
{
    IF(score > 80)
    {
        grade ← "B"
    }
    ELSE
    {
        grade ← "C"
    }
}

Now test the boundary. The requirement says a score of 90 should earn an "A." But the condition uses score > 90, which is false when the score is exactly 90. So the program falls through and assigns "B" instead.

A test using a "normal" score like 95 would pass and hide the bug. Only the boundary value of exactly 90 exposes it. The fix depends on the requirement: if 90 should be an "A," the condition should be score ≥ 90.

• Only testing normal inputs. Skipping edge and boundary cases lets serious bugs slip through.
• Assuming "it runs" means "it's correct." A program can run flawlessly and still be wrong.
• Changing many things at once. If you alter five things and the bug disappears, you do not know which fix worked.
• Not recording expected output. Without knowing what to expect, you cannot tell if a result is wrong.
• Ignoring boundary cases. The exact threshold values are where logic errors love to hide.

Whenever your program compares a value (greater than, less than, equal to a cutoff), write three test cases: one clearly below, one clearly above, and one exactly at the boundary. The boundary test is the one that most often reveals hidden logic errors, and describing it shows strong testing practice on the Create Performance Task.

Testing and debugging do not happen just once. Programs improve through repeated cycles of building, testing, and revising. In Iterative Development, you will see how prototypes, user feedback, and refinement turn a rough first version into a polished final program, tying together everything you have learned in Unit 1 and connecting directly to the Create Performance Task.