Nattrio🌱

Recent Notes

Rust Testing

4 min read

In Rust, when using parameterized tests with the rstest crate, the name of each test case is not explicitly required. Instead, you define the test cases using the #[case] attribute, and the rstest crate handles the generation of individual test cases based on the provided parameters.

Best Practices and Guidelines for Writing Parameterized Tests:

  1. Descriptive Test Names: While the rstest crate does not require explicit names for each test case, it is a good practice to write descriptive test names for the test functions themselves. This helps in understanding the purpose of the test at a glance.
  2. Clear and Concise Parameters: Ensure that the parameters provided in the #[case] attributes are clear and concise. This makes it easier to understand what each test case is testing.
  3. Use #[case] for Parameters: Use the #[case] attribute to define the input parameters and expected results for each test case. This keeps the test cases organized and easy to read.
  4. Document Edge Cases: Include edge cases and boundary conditions in your parameterized tests to ensure comprehensive coverage.
  5. Consistent Formatting: Maintain consistent formatting and indentation for readability.

Example:

Here’s an example of how to write parameterized tests using the rstest crate:

#[cfg(test)]
mod tests {
    use super::*;
    use rstest::rstest;
 
    #[rstest]
    #[case("Alice", "Hello, Alice!".to_string())]
    #[case("", "Hello, world!".to_string())]
    fn test_greet(#[case] input: &str, #[case] expected: String) {
        assert_eq!(expected, greet(input));
    }
 
    #[rstest]
    #[case(0, "You scored no points".to_string())]
    #[case(1, "You scored 1 point".to_string())]
    #[case(5, "You scored 5 points".to_string())]
    fn test_congrats(#[case] score: u32, #[case] expected: String) {
        assert_eq!(expected, congrats(score));
    }
}

Summary:

  • Test case names are not explicitly required when using rstest .
  • Focus on writing clear and descriptive test function names.
  • Use #[case] attributes to define parameters for each test case.
  • Follow best practices for readability and comprehensive test coverage.

The #[cfg(test)] attribute in Rust is used to conditionally compile the annotated code only when running tests. This attribute ensures that the code inside the module is included in the compilation process only when the cargo test command is executed. Here are the key reasons and differences:

Reasons to Use #[cfg(test)]:

  1. Separation of Test Code: It helps in keeping the test code separate from the production code. This makes the main codebase cleaner and easier to maintain.
  2. Conditional Compilation: The test code is only compiled and included in the binary when running tests. This avoids including test-related code in the final production binary, reducing its size and potential attack surface.
  3. Organization: It allows you to organize your tests in a dedicated module, making it easier to manage and locate test cases.

Differences from Not Using #[cfg(test)]:

  • Without #[cfg(test)]: The test code would be compiled and included in the binary even when not running tests, which is generally undesirable for production builds.
  • With #[cfg(test)]: The test code is only compiled and included when running tests, keeping the production binary clean and optimized.

Example:

With #[cfg(test)]:

#[cfg(test)]
mod tests {
    use super::*;
    use rstest::rstest;
 
    #[rstest]
    #[case("Alice", "Hello, Alice!".to_string())]
    #[case("", "Hello, world!".to_string())]
    fn test_greet(#[case] input: &str, #[case] expected: String) {
        assert_eq!(expected, greet(input));
    }
 
    #[rstest]
    #[case(0, "You scored no points".to_string())]
    #[case(1, "You scored 1 point".to_string())]
    #[case(5, "You scored 5 points".to_string())]
    fn test_congrats(#[case] score: u32, #[case] expected: String) {
        assert_eq!(expected, congrats(score));
    }
}

Without #[cfg(test)]:

mod tests {
    use super::*;
    use rstest::rstest;
 
    #[rstest]
    #[case("Alice", "Hello, Alice!".to_string())]
    #[case("", "Hello, world!".to_string())]
    fn test_greet(#[case] input: &str, #[case] expected: String) {
        assert_eq!(expected, greet(input));
    }
 
    #[rstest]
    #[case(0, "You scored no points".to_string())]
    #[case(1, "You scored 1 point".to_string())]
    #[case(5, "You scored 5 points".to_string())]
    fn test_congrats(#[case] score: u32, #[case] expected: String) {
        assert_eq!(expected, congrats(score));
    }
}

Summary:

  • Use #[cfg(test)] to conditionally compile test code only during testing.
  • Benefits: Keeps production binaries clean, reduces size, and separates test code from production code.
  • Without #[cfg(test)]: Test code would be included in the production binary, which is not ideal.

Reference

Graph View