The Rust Series: Automated Testing – Part 1

🎃 Personal Column:

🐬 Algorithm Design and Analysis: Algorithm Design and Analysis_IT Yan’s Blog – CSDN Blog

🐳 Java Basics: Java Basics_IT Yan’s Blog – CSDN Blog

🐋 C Language: C Language_IT Yan’s Blog – CSDN Blog

🐟 MySQL: Data Structure_IT Yan’s Blog – CSDN Blog

🐠 Data Structures: Data Structures_IT Yan’s Blog – CSDN Blog

💎 C++: C++_IT Yan’s Blog – CSDN Blog

🥽 C51 Microcontroller: C51 Microcontroller (STC89C516)_IT Yan’s Blog – CSDN Blog

Welcome to watch, hope it’s helpful for everyone!

Learning Recommendations:

In today’s rapidly developing information age, artificial intelligence (AI) has become an indispensable technological force, gradually transforming our lives, work, and even the entire social operation mode. From intelligent voice assistants to self-driving cars, from precision medicine to smart cities, AI applications have penetrated into all aspects of our lives. Therefore, learning and mastering knowledge and skills related to AI has become crucial for anyone who wants to remain competitive in this era.

However, artificial intelligence is an interdisciplinary field involving mathematics, computer science, data science, machine learning, neural networks, and more, with a relatively steep learning curve that may present challenges for beginners. Fortunately, with the abundance of internet educational resources, there are now numerous excellent online platforms and websites offering rich AI learning materials, including video tutorials, interactive courses, practical projects, etc., which undoubtedly open up a gateway to the world of artificial intelligence for learners.

Recently, I came across an outstanding AI learning website: Introduction – AI Tutorials, which is easy to understand and filled with humor. It’s hard not to want to share it with others.

Contents

🎯Writing and Running Tests

🎃Tests (Functions)

🎃Dissecting Test Functions

🎯 Assertion (Assert)

🎃 Using assert! Macros to Check Test Results

🎃 Using assert_eq! And assert_ne! To Test Equality

🎯 Custom Error Messages

🎯Using should_panic to Check Panics

🎃Make should_panic More Precise

🎯Using Result in Testing

🎯Writing and Running Tests

🎃Tests (Functions)

Testing functions in Rust are used to verify whether non-test code runs as expected. The body of a test function typically performs three main operations.

Set any required data or state
Run the code we want to test
Assert its result is what we expect

Test Success:

        Rust tests are functions annotated with the test attribute. Attributes are metadata about Rust code; an example is the derive attribute used in structs in Chapter 5. To turn a function into a test, add #[test] before the fn line. When running tests with cargo test, Rust builds a test execution binary that calls the annotated functions and reports whether each test passes or fails.

        Every time you create a new crate project with Cargo, it automatically generates a test module and one test function for us. This module provides a template for writing tests, so you don’t need to look up the exact structure and syntax of test functions each time you start a new project. Of course, you can also add any number of additional test functions or test modules.

        Before writing actual test code, let’s explore how tests work by experimenting with the automatically generated test templates. Then we’ll write some real tests that call our written code and assert the correctness of their behavior.

$ cargo new adder –lib Created library `adder` project $ cd adder

1
2
3

$ cargo new adder —lib
Created library `adder` project
$ cd adder

[crayon-67efc4dfceb39542410653 inline=”true” class=”language-rust”]#[cfg(test)] mod tests { #[test] fn it_works() { let result = 2 + 2; assert_eq!(result, 4);

1
2
3
4
5
6

[crayon–67efc4dfceb39542410653 inline=“true”  class=“language-rust”]#[cfg(test)]
mod tests {
#[test]
fn it_works() {
let result = 2 + 2;
assert_eq!(result, 4);

[/crayon]

        Now let’s temporarily ignore the tests module and the #[cfg(test)] annotation and focus solely on the function itself. Note the #[test] before the fn line: this attribute indicates that it’s a test function, allowing the test runner to treat it as such. The tests module can also contain non-test functions to help us establish common scenarios or perform routine operations; however, any function marked for testing must be explicitly designated.

        Test Failure:

        When a panic occurs in the test function, the test fails. Each test runs in a new thread, and when the main thread detects an exception in the test thread, it marks that test as failed.

#[cfg(test)] mod tests {     #[test]     fn exploration() {         assert_eq!(2 + 2, 4);     }     #[test]     fn another() {         panic!(“Make this test fail”);     } }

1
2
3
4
5
6
7
8
9
10
11

#[cfg(test)]
mod tests {
    #[test]
    fn exploration() {
        assert_eq!(2 + 2, 4);
    }
    #[test]
    fn another() {
        panic!(“Make this test fail”);
    }
}

🎯Assertions

Using the assert! macro to check test results

       The assert! macro, provided by the standard library, is very useful when we want to ensure that certain conditions are true in our tests. The assert! macro requires a parameter that evaluates to a boolean value. If the value is true, the assert! does nothing and the test passes; if the value is false, the assert! macro calls the panic! macro, causing the test to fail. The assert! macro helps us verify whether the code runs as expected.

        Testing functionality often involves comparing the value being tested to an expected value and checking if they are equal. This can be achieved by passing an expression using the == operator to the assert! macro. However, this operation is so common that the standard library provides a pair of macros to handle these operations more conveniently: assert_eq! and assert_ne!. These two macros check if two values are equal or not, respectively. When an assertion fails, they also print out the specific values of both operands, allowing us to observe why the test failed, whereas assert! only prints that it received false from the == expression without showing which values caused this.

#[derive(Debug)] struct Rectangle { width: u32, height: u32, } impl Rectangle { fn can_hold(&self, other: &Rectangle) -> bool { self.width > other.width && self.height > other.height } }

1
2
3
4
5
6
7
8
9
10

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}
impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

We pass the first parameter 4 to the assert_eq! macro, which equals the result of calling add_two(2). The line in the test test tests::it_adds_two ... ok indicates that the test passed with ok.

        Introduce a bug in the code to see what happens when the test fails using assert_eq!. Modify the implementation of the add_two function to add 3:

pub fn add_two(a: i32) -> i32 { a + 3 }

1
2
3

pub fn add_two(a: i32) -> i32 {
a + 3
}

[crayon-67efc4dfceb5b628456482 inline=”true” class=”language-rust”]$ cargo test Compiling adder v0.1.0 (file:///projects/adder) Finished test [unoptimized + debuginfo] target(s) in 0.61s Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) running 1 test test tests::it_adds_two … FAILED failures: —- tests::it_adds_two stdout —- thread ‘main’ panicked at ‘assertion failed: `(left == right)` left: `4`, right: `5`’, src/lib.rs:11:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: tests::it_adds_two test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[crayon–67efc4dfceb5b628456482 inline=“true”  class=“language-rust”]$ cargo test
Compiling adder v0.1.0 (file:///projects/adder)
Finished test [unoptimized + debuginfo] target(s) in 0.61s
Running unittests src/lib.rs (target/debug/deps/adder–92948b65e88960b4)
running 1 test
test tests::it_adds_two ... FAILED
failures:
—— tests::it_adds_two stdout ——
thread ‘main’ panicked at ‘assertion failed: `(left == right)`
left: `4`,
right: `5`’, src/lib.rs:11:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
tests::it_adds_two
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

[/crayon]

    Error: test failed, rerun with `–lib`

        Test captured a bug! [crayon-67efc4dfceb5d722814248 inline=”true” ]it_adds_two

1

        Test captured a bug! [crayon–67efc4dfceb5d722814248 inline=“true” ]it_adds_two

test failed, the error message tells us that an assertion failed and provides information about the assertion: assertion failed: `(left == right)`, as well as the values of left and right. This error message is helpful for debugging: it says that the left parameter in the assert_eq! macro is 4, while the right parameter, which is the result of add_two(2), is 5. This information is invaluable when dealing with numerous tests running simultaneously.

        It’s important to note that in some languages and testing frameworks, the parameters for functions that assert equality are referred to as expected and actual, and the order of these parameters matters significantly. However, in Rust, they are called left and right, andthe order in which we specify the expected value and the value produced by the tested code does not matter. The assertion in this test could also be written as assert_eq!(add_two(2), 4), yet the failure message remains the same: assertion failed: `(left == right)`.

   assert_ne! macro passes when the two values it is given are not equal, and fails when they are equal. This macro is most useful in situations where we are certain what a value should not be, rather than what it should be.

   assert_eq! and assert_ne! macros use the == and != operators respectively at their core. When an assertion fails, these macros print out their parameters using debug formatting, meaning that the values being compared must implement both PartialEq and Debug traits. All basic types and most standard library types implement these traits. For custom structs and enums, you need to derive or manually implement PartialEq to be able to assert whether their values are equal or not. You also need them to implement Debug so that their values can be printed when an assertion fails. Both of these traits are commonly derived.
[/crayon]

🎯 Custom Error Messages

       You can also pass an optional failure message parameter to the assert!、 assert_eq! and assert_ne! macros. This allows you to output custom failure messages along with the test results when a test fails.Any parameters specified after the required parameters of assert! (which has one) and the two required parameters of assert_eq! and assert_ne! are passed to the format! macro. This means you can pass a format string containing {} placeholders and the values you want inserted into those placeholders. Custom messages help in recording the purpose of the assertion; when a test fails, it becomes easier to understand what went wrong.

pub fn greeting(name: &str) -> String { format!(“Hello {}!”, name) } #[cfg(test)] mod tests { use super::*; #[test] fn greeting_contains_name() { let result = greeting(“Carol”); assert!(result.contains(“Carol”)); } }

1
2
3
4
5
6
7
8
9
10
11
12

pub fn greeting(name: &str) -> String {
format!(“Hello {}!”, name)
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn greeting_contains_name() {
let result = greeting(“Carol”);
assert!(result.contains(“Carol”));
}
}

        The requirements for this program have not yet been finalized, so the initial “Hello” text at the beginning of the greeting is likely to change. However, we don’t want to have to update the tests whenever the requirements change. Instead of checking that the greeting function returns an exact value, we will only assert that the output contains the input parameter in the text.

        Let’s introduce a bug by modifying the greeting to not include the name in the code to see what happens when the test fails:

pub fn greeting(name: &str) -> String { String::from(“Hello!”) }

1
2
3

pub fn greeting(name: &str) -> String {
String::from(“Hello!”)
}

        If we are only told that an assertion failed and the line number where it happened, a more useful failure message would print out the value of the greeting function. Let’s add a custom failure message parameter to the test function: a format string with placeholders and the value of the greeting function:

pub fn greeting(name: &str) -> String { String::from(“Hello!”) }

1
2
3

pub fn greeting(name: &str) -> String {
String::from(“Hello!”)
}

🎯 Using `should_panic` to Check for Panics

        In addition to checking the return values, it’s also important to verify whether the code handles errors as expected.

        We can achieve this by adding another attribute should_panic to the function. This attribute passes when the code in the function panics and fails if the code does not panic.

[crayon-67efc4dfceb89508609373 inline=”true” class=”language-rust”]pub struct Guess { value: i32, } impl Guess { pub fn new(value: i32) -> Guess { if value < 1 || value > 100 { panic!(“Guess value must be between 1 and 100, got {}.”, value);

1
2
3
4
5
6
7

[crayon–67efc4dfceb89508609373 inline=“true”  class=“language-rust”]pub struct Guess {
value: i32,
}
impl Guess {
pub fn new(value: i32) -> Guess {
if value < 1 || value > 100 {
panic!(“Guess value must be between 1 and 100, got {}.”, value);
guess { value }

}

}

#[cfg(test)]

mod tests {

use super::*;

#[test]

#[should_panic]

fn greater_than_100() {

Guess::new(200);

}

}
# 🎃Make `should_panic` More Precise
To make the `should_panic` test more precise, we can add an optional `expected` parameter to the `should_panic` attribute. This ensures that the error message contains the provided text.
[/crayon]
impl Guess {

pub fn new(value: i32) -> Guess {

if value < 1 {
panic!(
"Guess value must be greater than or equal to 1, got {}.",
value
);
} else if value > 100 {

panic!(

"Guess value must be less than or equal to 100, got {}.",

value

);

}

Guess { value }

}

}

#[cfg(test)]

mod tests {

use super::*;

#[test]

#[should_panic(expected = "less than or equal to 100")]

fn greater_than_100() {

Guess::new(200);

}

}

```
        This test will pass because the value provided by the 
			expected parameter in the 
			should_panic attribute is a substring of the panic message from the 
			Guess::new function. We can specify the entire panic message, which in this example is 
			Guess value must be less than or equal to 100, got 200.. The choice of 
			expected information depends on how unique or dynamic the panic message is and how precise you want the test to be. In this case, the substring of the error message is sufficient to ensure that the function runs under the condition 
			else if value > 100.

🎯In Tests Using Result<T, E>

So far, the tests we've written all panic on failure. We can also write tests using Result<T, E>! This is an extension of Example 11-1, rewritten to use Result<T, E> and return Err instead of panicking when it fails:

#[cfg(test)] mod tests { #[test] fn it_works() -> Result<(), String> { if 2 + 2 == 4 { Ok(()) } else { Err(String::from("two plus two does not equal four")) } } }

1
2
3
4
5
6
7
8
9
10
11

#[cfg(test)]
mod tests {
#[test]
fn it_works() -> Result<(), String> {
if 2 + 2 == 4 {
Ok(())
} else {
Err(String::from("two plus two does not equal four"))
}
}
}

Now the return type of the it_works function is Result<(), String>. In the function body, instead of calling the assert_eq! macro, it returns Ok(()) when the test passes and Err with a String when the test fails.

You should not use the #[should_panic] annotation for tests that use Result<T, E>.To assert that an operation returns an Err member,do notuse the question mark expression ( ?) on a Result<T, E> value. Instead, use assert!(value.is_err()).

10 responses to “The Rust Series: Automated Testing – Part 1”

Looking forward to more articles in this series to deepen my understanding of Rust testing.

Log in to Reply
This is an excellent starting point for anyone looking to implement automated testing in their Rust projects.

Log in to Reply
Thank you for this comprehensive guide—it’s filling a gap in my Rust knowledge regarding testing.

Log in to Reply
The section on using `Result` in tests was insightful and addresses scenarios I hadn’t considered before.

Log in to Reply
I appreciate the real-world examples provided; they helped me see how these testing techniques can be applied practically.

Log in to Reply
The article does an excellent job breaking down complex concepts into digestible parts. Highly recommended!

Log in to Reply
Learning about panics and how to test them with `should_panic` is something I can immediately apply in my projects.

Log in to Reply
The use of `assert_eq!` and `assert_ne!` was clearly explained, which I hadn’t fully grasped before.

Log in to Reply
I found the explanation of test functions and assertions particularly helpful for beginners like me.

Log in to Reply
This article is a great resource for understanding automated testing in Rust. The step-by-step guide and examples make it easy to follow.

Log in to Reply

IT Log