Junior · Testing and performance
Tests that prove behavior
What makes a good table-driven test?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Each case states an input, an observable expected result and the behavior it protects. Include boundaries and meaningful failure paths, not just a list of ordinary inputs.
Use subtest names to explain the scenario. Keep fixtures isolated and avoid mocks that merely repeat implementation calls; a fake at an external boundary should model realistic failures.
A passing test proves only its assertions on executed cases. Check errors, returned data and important side effects. Tests that accept either result or never assert a claimed invariant can pass while the bug remains.
Common trap
Coverage counts executed code; it does not show whether the assertions would catch a wrong answer.
Try it
For LowerBound, choose four cases that catch an off-by-one and a duplicate-boundary error.
Worked solution
Use empty input→0, target below all→0, target above all→n, and duplicate target→first equal index. Add a property that all elements before the answer are smaller and none at/after it are smaller.
Change the constraint
How would you show the test fails for the old buggy implementation?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.