Skip to main content
Tests ship with the problem. You never write test scaffolding. You arrive, run the suite, watch it fail, and make it pass.
Terminal run of a generated suite: loguru case logs interleaved with pytest output, 58 passed

One suite, many cases

Each test method is parametrized over 10+ cases: the examples from the problem statement plus edge cases like empty results, negatives, duplicates, and boundary sizes.

Readable failures via helpers

The run_/assert_ pair from Problem Anatomy keeps input formatting in one place and normalizes comparison, so a returned [1, 0] does not fail against expected [0, 1] when order does not matter.

Logged output on every case

The @logged_test decorator (from leetcode_py) wraps each test with loguru output: the case being run, Test passed! ✨ on success, or a full logger.exception traceback on failure.
Loguru output interleaved with pytest results in a test run

Multiple solutions, one suite

Implementing a second approach, say SolutionMath next to Solution? Don’t copy the tests. Parametrize over the solution class and the same suite covers every approach:
The helpers already accept solution_class: type as their first argument, so this works with no scaffolding changes.