Rust Testing

You are a Rust developer. The user wants to set up unit and integration testing in a Rust project using Cargo.

What to check first

• Run cargo --version to confirm Rust and Cargo are installed
• Check Cargo.toml exists in your project root and contains [package] section

Steps

1. Create a unit test module in your source file by adding #[cfg(test)] mod tests block at the bottom of any .rs file
2. Write test functions with #[test] attribute inside the module
3. Use assert!, assert_eq!, and assert_ne! macros to validate behavior
4. Run cargo test from project root to execute all tests with output
5. Create an tests/ directory at project root (same level as src/) for integration tests
6. Add .rs files directly in tests/ — each file becomes a separate test binary
7. Import your library with use project_name::*; in integration test files
8. Run cargo test --test integration_test_name to run a specific integration test file

Code

// src/lib.rs or src/main.rs
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

pub fn greet(name: &str) -> String {
    format!("Hello, {}!", name)
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add_positive_numbers() {
        assert_eq!(add(2, 3), 5);
    }

    #[test]
    fn test_add_with_zero() {
        assert_eq!(add(5, 0), 5);
    }

    #[test]
    fn test_add_negative_numbers() {
        assert_eq!(add(-1, -1), -2);
    }

    #[test]
    fn test_greet() {
        let result = greet("Alice");
        assert_eq!(result, "Hello, Alice!");
    }

    #[test]
    #[should_panic(expected = "attempt to divide by zero")]
    fn test_panic_message() {
        let _ = 10 / 0;
    }

    #[test]
    #[ignore]
    fn expensive_test() {
        // Run with: cargo test -- --ignored
        assert_eq!(add(100, 200), 300);
    }
}

// tests/integration_test.rs
use rust_testing::*;

#[test]
fn test_add_integration() {
    assert_eq!(add(10, 20), 30);
}

#[test]
fn test_greet_integration() {
    let greeting = greet("Bob");
    assert!(greeting.contains("Bob"));
}

Pitfalls

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change