Unit test generation

When to use this scenario

Automated test generation reads source code and produces unit tests — ideally covering edge cases that human developers routinely miss: null inputs, boundary values, concurrency races, exception paths. The quality metric is not coverage percentage (trivially gamed by asserting nothing) but mutation kill rate: how many deliberate code mutations does the test suite catch?

Input tokens carry the full source file plus type signatures and imports. At 4K tokens per file and 10K files/month, Qwen-3 Coder costs roughly $40/month at its per-token rate — about one-quarter the cost of Claude Sonnet for the same volume. For simpler utility functions and data-transformation code, the quality gap is small. For complex stateful business logic, Claude Sonnet produces more semantically complete tests that catch behavioral regressions.

A hybrid approach works well: run Qwen-3 Coder on all files above a coverage threshold baseline, escalate to Claude Sonnet for files flagged as high-risk (payment processing, auth, data migrations).

Common pitfalls

• Measuring success by line coverage — a test file that calls every line but asserts only truthy outcomes provides false confidence
• Not providing the function's dependency types and mock infrastructure — models guess interface shapes and produce tests that don't compile
• Generating tests for the current (possibly buggy) implementation rather than the spec — if the function has an existing bug, the test will encode the bug as expected behavior
• Ignoring test framework conventions: pytest fixtures vs unittest setUp, Jest mocks vs Vitest spies — mismatched patterns produce tests that run but look wrong to reviewers