Reproduce, Isolate, and Inspect
Unit ID: M06-U02 Estimated active time: 22-30 minutes
A reliable repair begins with reproduction
If a failure appears only sometimes, first record the exact input, environment, execution order, and steps that produce it.
Restart the kernel and run the smallest sequence that still fails. This separates a code defect from hidden notebook state.
Reduce the input
Instead of debugging seven records, try one:
failing_record = {"id": "R3", "hours": "six"}
Instead of the whole workflow, call the smallest relevant function:
parse_hours(failing_record["hours"])
If the small example fails in the same way, you have isolated the relevant behaviour.
Inspect without changing
raw_hours = failing_record.get("hours")
print(repr(raw_hours))
print(type(raw_hours))
repr() exposes quotation marks and escape characters, making spaces or text values easier to see.
Do not immediately convert, strip, or replace the value. First preserve what arrived.
Change one cause at a time
Test a focused hypothesis:
The parser assumes every input is a string containing numeric text.
Try " 8 ", 8, "six", True, and None. Record which fail and how. This reveals the current contract before you redesign it.
A minimal debugging table
| Input | Expected | Actual | Evidence |
|---|---|---|---|
" 8 " | 8 | 8 | passes |
8 | 8 | error | integer has no strip |
"six" | rejection | error | invalid integer text |
True | rejection | error or 1 | boolean requires explicit rule |
Practice
Take a failing record-processing script. Reduce it to one input and one function call. Use repr() and type(), then write one hypothesis before changing code.
Takeaway
Reproduce from clean state, reduce the data and call path, inspect the original value, and change one suspected cause. Next, validation will make accepted inputs explicit before risky operations.
