Review Checklist

Test Structure

• - [ ] Unit tests in #[cfg(test)] mod tests within source files
• [ ] Integration tests in tests/ directory (one file per module or feature)
• [ ] use super::* in test modules to access parent module items
• [ ] Test function names describe the scenario: INLINECODE19
• [ ] Tests are independent — no reliance on execution order

Async Tests

• - [ ] #[tokio::test] used for async test functions
• [ ] #[tokio::test(flavor = "multi_thread")] when testing multi-threaded behavior
• [ ] No block_on inside async tests (use .await directly)
• [ ] Test timeouts set for tests that could hang
• [ ] Mock traits use native async fn instead of async-trait crate (stable since Rust 1.75)

Assertions

• - [ ] assert_eq! / assert_ne! used for value comparisons (better error messages than assert!)
• [ ] Custom messages on assertions that aren't self-documenting
• [ ] matches! macro used for enum variant checking
• [ ] Error types checked with matches! or pattern matching, not string comparison
• [ ] One assertion per test where practical (easier to diagnose failures)
• [ ] if let assertions reviewed for edition 2024 temporary scope — temporaries in conditions drop earlier, may invalidate borrows
• [ ] Tail expression returns reviewed for edition 2024 — temporaries in tail expressions drop before local variables

Mocking and Test Doubles

• - [ ] Traits used as seams for dependency injection (not concrete types)
• [ ] Mock implementations kept minimal — only what the test needs
• [ ] No mocking of types you don't own (wrap external dependencies behind your own trait)
• [ ] Test fixtures as helper functions, not global state
• [ ] std::sync::LazyLock used for shared test fixtures instead of lazy_static! or once_cell (stable since Rust 1.80)

Error Path Testing

• - [ ] Result::Err variants tested, not just happy paths
• [ ] Specific error variants checked (not just "is error")
• [ ] #[should_panic] used sparingly — prefer Result-returning tests

Lint Suppression in Tests

• - [ ] #[expect(lint)] used instead of #[allow(lint)] for test-specific suppressions (stable since Rust 1.81)
• [ ] Justification comment on every #[expect] or #[allow] in test code
• [ ] Stale #[allow] attributes migrated to #[expect] for self-cleaning behavior

Test Naming

• - [ ] Test names read like sentences describing behavior (not test_happy_path)
• [ ] Related tests grouped in nested mod blocks for organization
• [ ] Test names follow pattern: INLINECODE46

Snapshot Testing

• - [ ] cargo insta used for complex structural output (JSON, YAML, HTML, CLI output)
• [ ] Snapshots are small and focused (not huge objects)
• [ ] Redactions used for unstable fields (timestamps, UUIDs)
• [ ] Snapshots committed to git in snapshots/ directory
• [ ] Simple values use assert_eq!, not snapshots

Parametrized Testing

• - [ ] rstest used to avoid duplicated test functions for similar inputs
• [ ] #[rstest] with #[case::name] attributes for descriptive parametrized tests
• [ ] #[fixture] used for shared test setup when multiple tests need same construction
• [ ] Parametrized tests still have descriptive case names (not just #[case(1)])
• [ ] Combined with async: #[rstest] #[tokio::test] for async parametrized tests

Doc Tests

• - [ ] Public API functions have /// # Examples with runnable code
• [ ] Doc tests serve as both documentation and correctness checks
• [ ] Hidden setup lines prefixed with # to keep examples clean
• [ ] cargo test --doc passes (nextest doesn't run doc tests)

Severity Calibration

Critical

• - Tests that pass but don't actually verify behavior (assertions on wrong values)
• Shared mutable state between tests causing flaky results
• Missing error path tests for security-critical code

Major

• - #[should_panic] without expected message (catches any panic, including wrong ones)
• INLINECODE61 in test setup that hides the real failure location
• Tests that depend on execution order
• INLINECODE62 with inline temporary in assertion that breaks under edition 2024 temporary scoping
• INLINECODE63 on mock traits when native async fn in traits is available and project targets edition 2024

Minor

• - Missing assertion messages on complex comparisons
• INLINECODE65 instead of assert_eq!(x, y) (worse error messages)
• Test names that don't describe the scenario
• Redundant setup code that could be extracted to a helper
• INLINECODE67 used where #[expect] would provide self-cleaning suppression
• INLINECODE69 or once_cell used for test fixtures when LazyLock is available

Informational

• - Suggestions to add property-based tests via proptest or INLINECODE73
• Suggestions to add snapshot testing for complex output
• Coverage improvement opportunities

Valid Patterns (Do NOT Flag)

• - unwrap() / expect() in tests — Panicking on unexpected errors is the correct test behavior
• use super::* in test modules — Standard pattern for accessing parent items
• #[allow(dead_code)] on test helpers — Helper functions may not be used in every test
• clone() in tests — Clarity over performance
• Large test functions — Integration tests can be long; extracting helpers isn't always clearer
• assert! for boolean checks — Fine when the expression is clearly boolean (.is_some(), .is_empty())
• Multiple assertions testing one logical behavior — Sometimes one behavior needs multiple checks
• unwrap() on Result-returning test functions — Propagating with ? is also fine but not required
• async-trait on mock traits requiring dyn dispatch — Native async fn in traits doesn't support dyn Trait; async-trait is still needed there
• #[expect] with justification on test helpers — Self-cleaning lint suppression is correct in test code
• LazyLock for expensive shared test fixtures — Thread-safe lazy init is appropriate for test globals

Before Submitting Findings

Load and follow beagle-rust:review-verification-protocol before reporting any issue.