Write a Test Harness
An empty tests/ folder fools no one. The moment a reviewer sees real tests, two things happen: they trust the code more, and they trust you more, because tests are proof you thought about what "correct" means. In the real repo you will run these with pytest (one command, covered next lesson). But under the hood, a test framework is not magic -> it is a loop that runs your function on known inputs and checks the output. Building that loop yourself, once, demystifies the whole thing.
So this lesson is testing, taught as plain deterministic code. You write a tiny harness:
run_checks(fn, cases)->casesis a list of(args_tuple, expected)pairs. Callfn(*args)for each case, compare the result toexpected, and return a list of{"args": args, "ok": bool}recording which cases passed. Iffnraises while you call it, that case is a failure (ok=False), not a crash that takes down the whole run -> a real test runner reports the failure and keeps going.all_pass(results)->Trueonly if there is at least one result and every one hasok=True. An empty result list means nothing was actually verified, so it is not a pass. This is the "green build" signal: one boolean that says the whole suite is good.
Why the "at least one" rule matters: a test suite that silently runs zero tests and reports success is worse than no tests, because it gives false confidence. Guarding the empty case is the difference between a harness that means something and one that always says yes.
Worked example. Say your project exposes add(a, b). You write cases [((1, 2), 3), ((0, 0), 0), ((5, 5), 10)]. A correct adder passes all three -> all_pass is True. A buggy version that subtracts returns -1, 0, 0 -> two cases fail, all_pass is False, and your harness just caught a regression. That is the entire value of tests in one sentence: a correct function and a broken one give you different answers, automatically.
Build with a simple try/except around the call so a raising function counts as a failed case. Press Run to harness a correct adder and see every case go green.
Build a minimal test harness. Write run_checks(fn, cases) where cases is a list of (args_tuple, expected): call fn(*args) for each, and return a list of {"args": args, "ok": bool} marking which cases match expected (a function that raises makes that case ok=False, no crash). Write all_pass(results) returning True only when there is at least one result and every ok is True (an empty list is False). A correct function and a buggy one must get different verdicts.
This lesson is locked
Lessons open one at a time. Finish the previous lesson to unlock this one.