rust-testinglisted

# Rust Testing A test suite is a statement about which changes the team refuses to accept silently. This skill decides *what deserves a test and in which form* — the five ordinary forms, golden files for file-shaped artifacts, and differential for ports — and it never decides what the code under test should look like. Shaping the code belongs to the craft skills; whether a change is tested at all, as a review verdict, is `/rust-code-review`. ## What a test is for A test exists to fail when behaviour changes. A test that restates the implementation — asserting that a getter returns the field it was handed — fails when the code is *refactored* and passes when the behaviour breaks, which is exactly backwards. Before writing a test, name the regression it would catch in one sentence. If that sentence is "the code changed," do not write the test. ## Pick the form from what is being asserted The form follows the assertion, not the habit. The depth on each form — where the file lives, what it can reach, what it costs — is in `TEST-DESIGN.md`; the one-line rule for each: | Form | Use it when | |---|---| | Unit test in `#[cfg(test)] mod tests` | The assertion needs private access, or the unit is a pure function with interesting edges | | Integration test in `tests/` | The assertion is about the public API a real caller sees — imports the crate as a consumer would | | Doc test | The example is documentation first; a doc test that is really a unit test in disguise belongs in `mod