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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.
