Fix a bug, and prove it stays fixed

A cleanup routine is supposed to remove every expired item from a list, and users report that some expired items survive. The code removes items from the list while iterating over it. Find the cause, write a test that fails because of it, then fix it. Hand in the test, the fix, and a short note. The note matters as much as the code: say what the failure was in terms of what Python actually does, not in terms of what the user saw.

Part of the Python Fundamentals course~75 minutesEvidence: a write-upWe mark it against a checklist you can read first

01 · What counts as done

What you have to hand in

A test that targets the reported failure, with a name that says what it covers.
A statement of what the test did before the fix, quoting the output.
The fix, confined to the cause.
Two or three sentences naming why the original loop skipped items.

02 · How it will be marked

The checklist, published before you start

We score your work against each line below, and every score has to quote the part of your work it is based on. You read all of it first, so you can argue with any score on the specifics.

The cause is named, not just the symptom30% of the grade
The submission says what was actually wrong, at the level of the line and the language rule involved — not merely what the user saw.
1. AbsentRestates the symptom, or describes the change without saying why it was needed.
2. DevelopingNames the region of the problem but not the rule that made it fail.
3. Competent— this is the pass markNames the line and the behaviour that caused it.
4. StrongNames the cause and rules out a plausible competing explanation.
A test that would have caught it30% of the grade
There is a test targeting the reported failure, and the write-up states what it did before the fix.
1. AbsentNo test, or a test that cannot fail regardless of the fix.
2. DevelopingA test exists but exercises a different case than the one reported.
3. Competent— this is the pass markA test covers the reported case, and the author says it failed before the fix.
4. StrongCovers the reported case and a neighbouring edge case, with the failure output quoted.
The fix is the smallest one that works25% of the grade
The change addresses the cause and does not rewrite surrounding code that was not implicated.
1. AbsentRewrites unrelated code, or changes behaviour the brief did not ask about.
2. DevelopingFixes it, but carries incidental refactoring along with it.
3. Competent— this is the pass markA targeted change confined to the cause.
4. StrongTargeted, with the larger rewrite explicitly considered and declined.
A colleague could follow it15% of the grade
Names say what things are; the diff can be read without the author present.
1. AbsentSingle-letter names, or a change that cannot be understood without asking.
2. DevelopingUnderstandable after a second read.
3. Competent— this is the pass markClear names and an obvious shape.
4. StrongReads as an explanation of the bug as well as a fix for it.

03 · What this proves

The skills a pass would prove

Pass, and these skills count as proven, with this piece of work attached as the evidence.

This brief is part of the Python Fundamentals course

Starting it starts the course: every skill above, in the order they depend on each other, with this brief at the end as the thing you hand in — marked against the checklist you have just read and nothing else.

About three minutes to set up: what you want to do with Python Fundamentals, where you are starting from, and how many hours a week you actually have. The subject we already have from this page.Start the Python Fundamentals course

See the whole Python Fundamentals course, or every graded brief we run.