FreeExam
A closed notebook, a blank card, and a pencil on a wooden desk.

Testing and debugging

20 cards

Failure reproduction, useful test oracles, boundary cases, dependency contracts, and verification that a fix addresses the cause.

Card 1 of 20

Front. Minimal Repro. What should be preserved while reducing a bug to a minimal reproduction?

These cards are original study material. They are not questions from a named employer or a live hiring loop.

All 20 cards in this deck

  1. 1.Minimal Repro

    What should be preserved while reducing a bug to a minimal reproduction?

    The failing behavior and the conditions that cause it. Remove unrelated code and data incrementally, checking that the failure still occurs after each reduction.

  2. 2.Regression Test

    What makes a regression test meaningful for a bug fix?

    It fails for the original defect and passes for the intended behavior, using a clear observable contract. A test that only mirrors the new implementation may preserve the same mistake.

  3. 3.Oracle

    Why can comparing an algorithm to a second implementation of the same logic miss a defect?

    Both can share the same assumption or bug. Use an independently justified reference, invariants, or examples with known results.

  4. 4.Property Test

    What property can test a sorting function beyond a few expected arrays?

    The output is ordered and preserves the input multiset. Either property alone is insufficient: returning an empty list is ordered but loses the elements.

  5. 5.Metamorphic

    How can testing a shortest-path implementation use a transformation when exact answers are expensive?

    For nonnegative weights, multiplying all weights by a positive constant should scale distances by that constant. Choose transformations that preserve the algorithm's assumptions and account for unreachable nodes.

  6. 6.Boundaries

    Why test empty, singleton, and maximum-size inputs separately?

    They exercise different control paths, such as missing initialization, off-by-one boundaries, and resource limits. Random middle-sized examples may never reach those defects.

  7. 7.Mock Boundary

    When can mocking every collaborator make a test suite give false confidence?

    Mocks can agree with the code while disagreeing with real protocols, serialization, or failure behavior. Keep focused unit tests and add contract or integration checks at important boundaries.

  8. 8.Fake Clock

    Why inject a clock into expiration logic instead of sleeping in tests?

    It makes time boundaries deterministic and fast to exercise. Test just before, exactly at, and after expiry using the documented inclusivity rule.

  9. 9.Flaky Test

    Why is repeatedly rerunning a flaky test until it passes not a fix?

    It hides nondeterminism and reduces trust in failures. Identify uncontrolled time, ordering, shared state, or infrastructure conditions and make the intended behavior reproducible.

  10. 10.Random Seed

    What should a randomized test record when it fails?

    The seed and preferably a minimized concrete failing input, plus relevant environment details. A seed alone may not reproduce the case after generator or dependency changes.

  11. 11.Coverage Limit

    Why does 100% line coverage not establish correctness?

    Executing a line does not prove its result was checked or all combinations were exercised. Assess assertions, boundary behavior, and meaningful failure modes.

  12. 12.Mutation Test

    What does a surviving mutation suggest about a test suite?

    A deliberate behavior change was not detected, unless the mutation is equivalent or unreachable. Use it to investigate weak assertions rather than treating one score as a complete quality measure.

  13. 13.Snapshot Review

    Why can accepting a large updated snapshot accidentally approve a regression?

    The diff may contain unintended behavior hidden among formatting changes. Keep snapshots focused and review semantic changes, with explicit assertions for critical invariants.

  14. 14.Error Path

    Why should a file-processing test inject a write failure after some output is produced?

    It exercises cleanup, partial-result visibility, and retry behavior that an immediate failure misses. Assert the externally visible recovery contract.

  15. 15.Resource Leak

    How can a test reveal a connection leak that one successful request misses?

    Repeat the operation and relevant failure paths while observing bounded resource use. Verify resources are released after exceptions and cancellation as well as success.

  16. 16.Bisection

    When does version-control bisection work well for finding a regression?

    When a reliable test distinguishes good and bad revisions and intermediate revisions can be evaluated. Handle unrelated build failures explicitly rather than labeling them as the target defect.

  17. 17.Logs Hypothesis

    How should temporary diagnostic logging be chosen during debugging?

    Instrument the smallest set of events that distinguishes competing explanations, including identity and ordering. Avoid dumping entire objects without a hypothesis.

  18. 18.Concurrency Schedule

    Why are barriers more useful than arbitrary sleeps for reproducing a race?

    They force the critical ordering, such as both workers reading before either writes. Sleeps merely hope the scheduler produces that interleaving.

  19. 19.Fix Cause

    A null check stops a crash. What must still be established before calling the bug fixed?

    Whether null is a valid state and what behavior is required there. Suppressing the exception may conceal an upstream invariant violation or silently drop work.

  20. 20.Verification Scope

    How should verification scope follow a localized code change?

    Test the corrected behavior and plausible affected contracts, then run required project checks. Add broader tests when dependencies or failure evidence justify them, not by repeatedly running unrelated suites.