Unit Tests: Deciding What Is Worth Testing
Writing small automated checks that call one function with chosen inputs and assert what should come back. The value is in the cases picked: the boundary, the empty input, the failure that should be raised.
What a learner can do afterwards
- Write tests for one function covering a normal case, a boundary and an error case
- Change the function so a test fails, and read what the failure tells you
- Say why a test that only repeats the code's own logic proves nothing
1 · Read
A unit test is a small automated check that calls one function and asserts what should come back. You run the suite without clicking by hand, and you rerun it after every change. That safety net lets you reshape code boldly, since a broken promise shows within seconds.
You give one function at least three tests: a normal case, a boundary like empty or zero, and an error case that must fail loudly and cleanly. A bill splitter gets a normal split, a zero total boundary, and a people count of zero that must raise instead of crashing the suite.
A failing test should name the broken promise well enough to guide your fix. You check a test proves anything by breaking the function on purpose: if the test still passes, it proves nothing and you rewrite it. A test that only repeats the code own logic copies the same mistake twice, so you restate the promise independently.
You plan tests alongside coding, promise by promise, not after release. Error cases earn their own tests because happy paths lie: only bad inputs prove the function raises clearly instead of passing silently.
Normal plus boundary plus error, planned early, each failure pointing at the fix.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.