rust-write-tests

Rust Test Writing Skill

Write tests that catch real bugs. Every test must guard a specific invariant -- not just prove the code "works."

The "What Could Break?" Framework

Before writing any test, answer these four questions:

1. What invariant does this code maintain? (e.g., "deserialized config always has a default profile")
2. What edge case would violate it? (e.g., "empty TOML table, missing key, extra unknown key")
3. What platform difference could surface? (e.g., "path separators, case sensitivity, symlink behavior")
4. What would a future refactor accidentally break? (e.g., "field added to struct but not to Display impl")

If you can only answer #1, your test is a happy-path test. Answer all four and you have a regression suite.

The 5 Test Transformations

Each transformation shows a superficial test pattern and its expert replacement.

Transformation 1: Weak assertions -> whole-object comparison

// BEFORE: proves nothing about the rest of the struct
let result = parse_config(input)?;
assert!(result.is_ok());

// AFTER: catches any unexpected field change
use pretty_assertions::assert_eq;
let result = parse_config(input)?;
assert_eq!(result, Config {
    name: "default".into(),
    timeout: Duration::from_secs(30),
    retries: 3,
    verbose: false,
});

Transformation 2: Single happy-path -> targeted test suite

// BEFORE: one test, one path
#[test]
fn test_parse_config() {
    let cfg = parse("valid input").unwrap();
    assert!(cfg.is_valid());
}

// AFTER: 3-6 tests covering happy, error, edge, platform
#[test]
fn parse_config_returns_defaults_for_minimal_input() { .. }
#[test]
fn parse_config_rejects_negative_timeout() { .. }
#[test]
fn parse_config_preserves_unknown_fields_as_extensions() { .. }
#[test]
fn parse_config_handles_empty_string_gracefully() { .. }
#[cfg(windows)]
#[test]
fn parse_config_normalizes_backslash_paths() { .. }

Transformation 3: Inline test module -> sibling _tests.rs file