Community resourceWorksheet
OCR H446 2.2.1 IDE development and debugging
Part 8 of 14 · H446 2.2.1 · Programming techniques
Naming IDE features earns little on its own; H446 2.2.1 rewards linking a feature to the evidence it produces. A podcast queue that drops its final episode drives a reproduce, predict, inspect, repair and retest routine, so breakpoints, watches and tests are each used for a stated purpose.
Students will:
- distinguish syntax, runtime and logic errors from the behaviour observed
- choose a breakpoint position and name the values worth watching there
- explain what a variable watch shows that a passing or failing test does not
- repair a loop so it processes every item, including empty and one-item lists
- describe an investigation order that confirms a fault before any code is changed
Inside: 7 explanation cells, 2 multiple-choice questions, 1 fill-in-the-blanks cell, 2 written answers and 2 Python tasks. 16 marks, about 25 to 35 minutes.
Series: H446 2.2.1 · Programming techniques, part 8 of 14.
Shared by Coding PathwayVerified teacher
- 14 cells
- About 30 minutes
- CC BY-SA 4.0
- Shared 31 Aug 2026
- Updated 3 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
IDE development and debugging
A podcast queue skips its final episode. IDE features are useful only when connected to a deliberate investigation.
By the end, you will be able to
- distinguish syntax, runtime and logic errors
- choose a breakpoint and watched values
- step through a fault in execution order
- design unit tests for ordinary and boundary cases
Reactivate: control-flow tracing and boundary testing.
Features with purposes
An IDE combines development tools in one environment. The exact features vary, so an examination answer should name the feature, describe the action it performs and link that action to useful evidence.
- Code editor, autocomplete and syntax highlighting support writing and reading code; autocomplete suggests known names, while highlighting makes token types and structure easier to inspect.
- Error diagnostics report detected errors, often with a location and possible cause. They can reveal syntax errors but cannot prove that the program's logic matches its purpose.
- Runtime environment and translator let the developer execute or translate the program without manually switching tools.
- Breakpoint pauses at a chosen statement.
- Stepping executes one statement at a time.
- Variable watch shows selected runtime values.
- Unit tests run a small component with known inputs and expected results.
A syntax error breaks the language rules; a runtime error occurs during execution; a logic error allows execution but produces incorrect behaviour.
Model a debugging workflow
Symptom: final episode missing.
- Reproduce with a three-item list.
- Predict valid indexes: 0, 1, 2.
- Break inside the loop and watch index and len(episodes).
- Observe index values 0, 1 only.
- Inspect range(len(episodes) - 1), repair it, then rerun empty, one-item and three-item unit tests.
Autocomplete may prevent a mistyped name, but it cannot prove this loop bound is logically correct. Link every feature to the evidence it reveals.
Worked diagnosis
Suppose the expected result is all three episode names, but the program returns only the first two without raising an exception. That evidence rules out a syntax failure and points to a logic error.
A useful workflow is: run a focused three-item test → pause inside the loop → watch index and len(episodes) while stepping → observe that index never reaches 2 → inspect and correct the loop bound → rerun empty, one-item and three-item tests. Each tool contributes different evidence.
The podcast program runs without an exception but omits the final episode. What type of error is this?
- ASyntax error
- BRuntime error
- CLogic error
- DTranslation error
To inspect index immediately before an incorrect list access, which feature is most directly useful?
- AAutocomplete
- BColour theme
- CFile compression
- DBreakpoint with variable watch
def play_order(episodes):
played = []
for index in range(len(episodes) - 1):
played.append(episodes[index])
return played
print(play_order(["Intro", "Interview", "Credits"]))Choose a line for a breakpoint and state what values you would watch to confirm why the final episode is skipped.
Link the pause point and values to the loop bound.
Students type their answer here.
Repair and test
Correct play_order so it returns every episode in the same order, including empty and one-item lists.
def play_order(episodes):
played = []
for index in range(len(episodes) - 1):
played.append(episodes[index])
return playedExplain how unit testing and a variable watch contribute different evidence while debugging this function.
State what each reveals in this specific program.
Students type their answer here.
Checkpoint
Complete the debugging workflow from memory. There is no answer bank, and correctness is withheld until teacher review.
Review your understanding
Before submitting, check that you can explain the main distinction in your own words, apply it in an unfamiliar context and justify the resulting behaviour or consequence.