dev-tdd

Start with the smallest tracer bullet: write one failing test that exercises the behavior through the public interface, implement only enough code to pass, then refactor while green. Repeat with the next behavior rather than batching tests ahead of implementation.

Red-green-refactor is the core TDD loop: write a test that fails for the right reason (red), write minimal code to make it pass (green), then improve the code structure while keeping all tests passing (refactor). Never refactor while tests are failing.

Assert a distribution over multiple seeds, such as a median recovery metric, rather than a single-seed threshold. A lucky seed can hide seed-dependent failures, so single-run assertions pass vacuously even when the method is broken.

A fixture written by one test and read by the next passes vacuously when the writer stops running, because the later test asserts against data it never produced. Rebuild or truncate shared fixture state per test case to keep each assertion meaningful.

Pin behavior with a characterization test before changing code where being subtly wrong is silently critical: losses, samplers, custom gradients, numerical kernels, serialization, and public APIs. Code that fails loudly or has no meaningful behavior does not need one.

Unit-green alone never proves a pipeline works; primary completion evidence is an end-to-end test through the real entry point such as the CLI or train step. Reserve isolated unit tests for logic tricky enough to earn them.