Master Rust Test Module Creation

This skill writes comprehensive, well-structured test modules for Rust code, covering unit tests, integration tests, documentation tests, and property tests. It structures tests using #[cfg(test)] conditionally compiled modules, use super::*; imports, nested modules for grouping, and the naming convention test_function_name_condition_expected_result. It generates patterns for advanced assertions (Result handling, floating-point comparison with tolerance, collection contents), parameterized tests iterating over multiple input/expected-output cases, mock/test-double objects for isolating dependencies, async tests using #[tokio::test] including timeout behavior, integration tests exercising a system's public API end-to-end, custom test fixtures/helpers, structured error-condition tests matching on specific error variants, and performance benchmark tests asserting on elapsed duration.

#[cfg(test)]
mod async_tests {
    use super::*;
    use tokio::test;
    
    #[tokio::test]
    async fn test_async_function() {
        let result = async_operation().await;
        assert!(result.is_ok());
    }
    
    #[tokio::test]
    async fn test_timeout_behavior() {
        use tokio::time::{timeout, Duration};
        
        let result = timeout(
            Duration::from_millis(100),
            slow_async_operation()
        ).await;
        
        assert!(result.is_err()); // Should timeout
    }
}

Use it when writing or expanding test coverage for Rust code and you want tests organized with idiomatic Rust conventions - #[cfg(test)] modules, AAA structure, descriptive naming - across unit, integration, async, and mocked-dependency scenarios, including parameterized test cases and performance assertions. It also covers structured error testing that matches on specific error enum variants (e.g. Err(MyError::InvalidInput(msg))) rather than only asserting an error occurred, and custom test fixtures/helper functions (like a create_test_user() builder or a setup_test_environment() helper) for reusable setup across multiple tests.

It is not a fuzzing or property-based-testing framework itself (property tests are named as a category but no proptest/quickcheck integration is included), and it does not run or execute tests - it produces the Rust test source code for you to compile and run with cargo test.

Input is the Rust function, module, or system to be tested, along with the testing scenario needed (unit, integration, async, mocked, parameterized, error-path, fixture-based, or performance). Output is idiomatic Rust test module code using #[cfg(test)], #[test] or #[tokio::test] attributes, assert!/assert_eq! assertions, and, where relevant, #[should_panic(expected = ...)] for expected-panic cases or #[ignore] for expensive tests excluded from default runs. Performance tests are generated using std::time::Instant to measure elapsed duration and assert it stays under a threshold, and error-path tests use match on the Result to verify the specific error variant and message content rather than a generic failure check.

Throughout, the skill favors keeping tests close to the code they test, using descriptive scenario-based test names, and grouping related tests in nested modules so a test file stays navigable as coverage grows.

Rust developers practicing TDD or adding structured test coverage - unit, integration, async, and mocked scenarios - who want tests generated with idiomatic module structure and naming conventions rather than writing each test category from scratch.