Unit Tests: Deciding What Is Worth Testing · seed 1 · A4, ink-friendly. The answer key prints on its own page for grown-ups.

Tests that actually prove something

Computing · Programming · ages 17-18
Name ______________________   Date ____________

  1. Which input is a boundary case?

    • A typical full basket
    • An empty string or zero
    • A second normal basket

  2. What minimum set should one function get?

    • Three normal cases
    • Normal plus boundary plus error
    • Three error cases

  3. Good tests run automatically, without a human clicking through screens.

    Circle one:   True   False

  4. How do you check a new test actually tests anything?

    • Run it once while green
    • Break the function and demand a failure
    • Delete the function

  5. A test fails. What should its message give you?

    • The broken promise, precisely enough to guide the fix
    • Louder output with no detail
    • A new feature idea

  6. Why is a test that repeats the code own logic worthless?

    • It runs too fast
    • It copies the same mistake twice
    • It needs no computer

  7. A suite stays green though empty input crashes users. What is the diagnosis?

    • Tests run too often
    • Too many tests exist
    • No boundary or error test covers empty input

  8. A bill splitter has normal and boundary tests but none for zero people. What is missing?

    • An error case that must raise cleanly
    • A prettier output message
    • A faster computer
LightMySky · lightmysky.comW1-mt_tuIQecq5Le-s1

Answer key

For grown-ups. Fold this page away before handing over the rest.

Tests that actually prove something W1-mt_tuIQecq5Le-s1

  1. An empty string or zero · Boundaries sit at the edge of allowed input.
  2. Normal plus boundary plus error · The trio covers tidy input, edges, and failure.
  3. True · Automation lets the suite rerun after every change.
  4. Break the function and demand a failure · A test that passes on broken code proves nothing.
  5. The broken promise, precisely enough to guide the fix · A sharp failure names what broke and where.
  6. It copies the same mistake twice · Tests must restate the promise independently.
  7. No boundary or error test covers empty input · Happy paths lie, so untested edges break in front of users.
  8. An error case that must raise cleanly · Zero people is the failure the code must survive loudly.
Worksheet · LightMySky