Unit Testing

Plan a complete unit test case system for the production code in scope, see what existing tests already cover, fill the gaps, and finally prune. Core methodology: think through the ideal case system first, then compare it against reality — to avoid being anchored by existing tests and to avoid omissions.

Core Principles

• Plan before auditing: independently plan what test cases each function/method should have, then look at what existing tests already accomplish. Looking at existing tests first will bias you, and a sense of "seems enough" will make you miss what should be tested.
• Isolate the unit under test: when testing function A, if A calls B, assume B is correct, mock B, and verify only that A's interaction with B — its inputs and outputs — meets expectations. Never elaborate various cases within A's test to prove B correct — B has its own tests. Once this boundary is broken, a bug in a collaborator turns the tests of every function that calls it red en masse, making attribution chaotic.
• Accept tests you cannot write: some unit tests are genuinely hard to write — mock cost is too high, test data cannot be prepared, or a god class resists thorough testing. This is not the executor's fault — drop it decisively rather than cobbling together a brittle or vacuous test. When dropping, note the reason in the case plan.
• Repeated runs should converge: this skill may be run repeatedly to catch and fill gaps. A healthy repeated-run result is "very few additions," not a fresh batch of gaps every time. If every run still misses a lot, the problem lies in the depth of planning or auditing, not the code.

Scope

Parse the user arguments to determine the scope for writing unit tests: