Implementing & Testing Solutions

AQA 4.13.1 — Implementing and testing computational solutions

Retrieval: the previous lesson designed (not yet coded) a solution to the badminton-booking sub-problems. This lesson implements one of them, and — just as importantly — tests it the way a real solution has to be tested, not just run once and eyeballed.

Key vocabulary

• Incremental development — building and testing a solution in small, working stages, rather than writing the whole thing before running any of it.
• Test plan — a table of planned test cases (input, expected output, purpose) written before or alongside implementation, not invented after the fact to match whatever the code happens to do.
• Normal, boundary and erroneous data — the three categories a genuinely thorough test plan should cover: typical valid input; input right at the edge of what's valid; and input that should be rejected or handled safely.
• Validation vs. verification — validation checks input is reasonable before processing it (e.g. rejecting a negative court number); verification checks the solution as a whole meets the original requirement.

Understand — why a test plan comes before "does it look right"

Running a program once on an input you expect to work and seeing a plausible-looking answer is not testing — it's a single, unrepresentative anecdote. A genuine test plan is written against the specification (Lesson 1), independently of the implementation, so it can catch cases the implementation happens to get wrong without the tester unconsciously only trying inputs they already expect to succeed.

See it — a real test plan, for the overlap-checking sub-problem

The two boundary cases specifically probe "does the overlap check use < or <=" — exactly the kind of off-by-one mistake that only a genuine boundary test, not a single "normal" run, would ever catch.

Implement it — the same problem, deliberately without a specified approach

Complete the Court Booking Overlap Check coding challenge: given a requested start/end time and a list of existing bookings for one court, determine whether the requested time overlaps any existing booking. You decide the data representation and approach — tuples, dictionaries, a class, a loop, or a functional filter-based check are all legitimate; what matters is that your solution is correct against a test plan like the one above, not which specific tool you reached for.

Debug it — diagnose, explain, fix, test, justify (an incomplete test plan)

A classmate's test plan for the same overlap-checking function contains only these two rows: "10:00–11:00 requested, no existing bookings → free" and "10:00–11:00 requested, existing 10:00–11:00 → taken." Their implementation passes both tests, but is later found to incorrectly report a court as free when a requested 10:00–11:00 slot partially overlaps an existing 10:30–11:30 booking.

1. Diagnose: which category of test data (normal, boundary, or erroneous) is entirely missing from this test plan, and how does that connect directly to the bug that slipped through?
2. Explain: why do both of the original two tests pass even though the underlying overlap-checking logic is broken?
3. Fix: state (in words) a correct general rule for two time ranges overlapping, that a boundary test like the partial-overlap case above would actually verify.
4. Test: propose one additional boundary test case that would have caught this specific bug.
5. Justify: explain why "the code passed all the tests I wrote" is not, by itself, evidence that a solution is correct.

(The missing category is boundary/partial-overlap data - both existing tests are either "no overlap at all" or "identical, fully-overlapping" times; neither tests a PARTIAL overlap, which is exactly the case that broke. Both original tests pass because the flawed logic likely only checks for exact or full-range matches, which both original tests happen to be examples of - the specific gap in the logic was never exercised. A correct general rule: two ranges [startA, endA] and [startB, endB] overlap if startA < endB and startB < endA - this correctly catches partial overlaps in either direction. An additional test: 10:00-11:00 requested vs an existing 10:30-11:30 booking, expecting "overlap." Passing tests only proves a solution behaves correctly on the SPECIFIC inputs tested - a test plan that never exercises a case provides zero evidence about that case, however many other tests pass.)

Common mistake

Writing a test plan that only contains cases the implementation is already known to handle correctly. A test plan's value comes specifically from trying to find cases where a solution might be wrong — boundary and erroneous data are where most real bugs hide, precisely because they're the cases a first, "does it basically work" pass tends to skip.

Check your understanding

State one erroneous-data test case for the badminton-booking system's "book a court" function, and state what a correct implementation should do with it (not necessarily what it currently does). (E.g. a booking request for a court number that doesn't exist (court 9, when only 4 exist) - a correct implementation should reject it safely, not crash or silently create a new, invalid booking. Any genuinely invalid/unexpected input with a stated safe handling behaviour is acceptable.)

Challenge

Extend your overlap-checking implementation to handle a court with an existing list of multiple bookings in one day, not just one — state what changed about your approach, if anything, and why.

Looking ahead: the final lesson steps back from "does it work" to "is it actually a good solution" — evaluating against the original requirements, not just the test plan.