diff --git a/ci/dictionary.txt b/ci/dictionary.txt index e54b164f19..6329ed1238 100644 --- a/ci/dictionary.txt +++ b/ci/dictionary.txt @@ -429,6 +429,7 @@ Rustaceans rUsT rustc rustdoc +RUSTFLAGS Rustonomicon rustfix rustfmt diff --git a/listings/ch11-writing-automated-tests/listing-11-03/src/lib.rs b/listings/ch11-writing-automated-tests/listing-11-03/src/lib.rs index 0db269085f..866f0238ba 100644 --- a/listings/ch11-writing-automated-tests/listing-11-03/src/lib.rs +++ b/listings/ch11-writing-automated-tests/listing-11-03/src/lib.rs @@ -1,4 +1,3 @@ -// ANCHOR: here pub fn add(left: usize, right: usize) -> usize { left + right } @@ -18,4 +17,3 @@ mod tests { panic!("Make this test fail"); } } -// ANCHOR_END: here diff --git a/listings/ch11-writing-automated-tests/listing-11-05/src/lib.rs b/listings/ch11-writing-automated-tests/listing-11-05/src/lib.rs index 0f1bc4e084..0a03a2b447 100644 --- a/listings/ch11-writing-automated-tests/listing-11-05/src/lib.rs +++ b/listings/ch11-writing-automated-tests/listing-11-05/src/lib.rs @@ -1,4 +1,3 @@ -// ANCHOR: here #[derive(Debug)] struct Rectangle { width: u32, @@ -10,4 +9,3 @@ impl Rectangle { self.width > other.width && self.height > other.height } } -// ANCHOR_END: here diff --git a/listings/ch11-writing-automated-tests/listing-11-07/src/lib.rs b/listings/ch11-writing-automated-tests/listing-11-07/src/lib.rs index 3e5d66bfaf..682e8ae172 100644 --- a/listings/ch11-writing-automated-tests/listing-11-07/src/lib.rs +++ b/listings/ch11-writing-automated-tests/listing-11-07/src/lib.rs @@ -1,4 +1,4 @@ -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { a + 2 } @@ -8,6 +8,7 @@ mod tests { #[test] fn it_adds_two() { - assert_eq!(4, add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } } diff --git a/listings/ch11-writing-automated-tests/listing-11-10/output.txt b/listings/ch11-writing-automated-tests/listing-11-10/output.txt index 36fae57883..c67b607d8c 100644 --- a/listings/ch11-writing-automated-tests/listing-11-10/output.txt +++ b/listings/ch11-writing-automated-tests/listing-11-10/output.txt @@ -13,8 +13,8 @@ failures: I got the value 8 thread 'tests::this_test_will_fail' panicked at src/lib.rs:19:9: assertion `left == right` failed - left: 5 - right: 10 + left: 10 + right: 5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace diff --git a/listings/ch11-writing-automated-tests/listing-11-10/src/lib.rs b/listings/ch11-writing-automated-tests/listing-11-10/src/lib.rs index 99fc06b8d6..3fbde2a1ed 100644 --- a/listings/ch11-writing-automated-tests/listing-11-10/src/lib.rs +++ b/listings/ch11-writing-automated-tests/listing-11-10/src/lib.rs @@ -10,12 +10,12 @@ mod tests { #[test] fn this_test_will_pass() { let value = prints_and_returns_10(4); - assert_eq!(10, value); + assert_eq!(value, 10); } #[test] fn this_test_will_fail() { let value = prints_and_returns_10(8); - assert_eq!(5, value); + assert_eq!(value, 5); } } diff --git a/listings/ch11-writing-automated-tests/listing-11-11/src/lib.rs b/listings/ch11-writing-automated-tests/listing-11-11/src/lib.rs index f56715263e..ccf1eb2a2f 100644 --- a/listings/ch11-writing-automated-tests/listing-11-11/src/lib.rs +++ b/listings/ch11-writing-automated-tests/listing-11-11/src/lib.rs @@ -1,4 +1,4 @@ -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { a + 2 } @@ -8,16 +8,19 @@ mod tests { #[test] fn add_two_and_two() { - assert_eq!(4, add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } #[test] fn add_three_and_two() { - assert_eq!(5, add_two(3)); + let result = add_two(3); + assert_eq!(result, 5); } #[test] fn one_hundred() { - assert_eq!(102, add_two(100)); + let result = add_two(100); + assert_eq!(result, 102); } } diff --git a/listings/ch11-writing-automated-tests/listing-11-12/src/lib.rs b/listings/ch11-writing-automated-tests/listing-11-12/src/lib.rs index c3961b1f62..9ba15d8b22 100644 --- a/listings/ch11-writing-automated-tests/listing-11-12/src/lib.rs +++ b/listings/ch11-writing-automated-tests/listing-11-12/src/lib.rs @@ -1,9 +1,9 @@ -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { internal_adder(a, 2) } -fn internal_adder(a: i32, b: i32) -> i32 { - a + b +fn internal_adder(left: usize, right: usize) -> usize { + left + right } #[cfg(test)] @@ -12,6 +12,7 @@ mod tests { #[test] fn internal() { - assert_eq!(4, internal_adder(2, 2)); + let result = internal_adder(2, 2); + assert_eq!(result, 4); } } diff --git a/listings/ch11-writing-automated-tests/listing-11-13/src/lib.rs b/listings/ch11-writing-automated-tests/listing-11-13/src/lib.rs index c3961b1f62..9ba15d8b22 100644 --- a/listings/ch11-writing-automated-tests/listing-11-13/src/lib.rs +++ b/listings/ch11-writing-automated-tests/listing-11-13/src/lib.rs @@ -1,9 +1,9 @@ -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { internal_adder(a, 2) } -fn internal_adder(a: i32, b: i32) -> i32 { - a + b +fn internal_adder(left: usize, right: usize) -> usize { + left + right } #[cfg(test)] @@ -12,6 +12,7 @@ mod tests { #[test] fn internal() { - assert_eq!(4, internal_adder(2, 2)); + let result = internal_adder(2, 2); + assert_eq!(result, 4); } } diff --git a/listings/ch11-writing-automated-tests/listing-11-13/tests/integration_test.rs b/listings/ch11-writing-automated-tests/listing-11-13/tests/integration_test.rs index 3822d6b976..d6b88a7505 100644 --- a/listings/ch11-writing-automated-tests/listing-11-13/tests/integration_test.rs +++ b/listings/ch11-writing-automated-tests/listing-11-13/tests/integration_test.rs @@ -2,5 +2,6 @@ use adder::add_two; #[test] fn it_adds_two() { - assert_eq!(4, add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } diff --git a/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/output.txt b/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/output.txt index eb925aa9b9..927f89144c 100644 --- a/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/output.txt +++ b/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/output.txt @@ -9,7 +9,7 @@ test tests::it_adds_two ... FAILED failures: ---- tests::it_adds_two stdout ---- -thread 'tests::it_adds_two' panicked at src/lib.rs:11:9: +thread 'tests::it_adds_two' panicked at src/lib.rs:12:9: assertion `left == right` failed left: 5 right: 4 diff --git a/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/src/lib.rs b/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/src/lib.rs index d7b4e139b8..aed772b0ea 100644 --- a/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/src/lib.rs +++ b/listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/src/lib.rs @@ -1,5 +1,5 @@ // ANCHOR: here -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { a + 3 } // ANCHOR_END: here @@ -10,6 +10,7 @@ mod tests { #[test] fn it_adds_two() { - assert_eq!(add_two(2), 4); + let result = add_two(2); + assert_eq!(result, 4); } } diff --git a/listings/ch11-writing-automated-tests/no-listing-07-custom-failure-message/src/lib.rs b/listings/ch11-writing-automated-tests/no-listing-07-custom-failure-message/src/lib.rs index 519c7a4c6f..8bbaca53fd 100644 --- a/listings/ch11-writing-automated-tests/no-listing-07-custom-failure-message/src/lib.rs +++ b/listings/ch11-writing-automated-tests/no-listing-07-custom-failure-message/src/lib.rs @@ -12,8 +12,7 @@ mod tests { let result = greeting("Carol"); assert!( result.contains("Carol"), - "Greeting did not contain name, value was `{}`", - result + "Greeting did not contain name, value was `{result}`" ); } // ANCHOR_END: here diff --git a/listings/ch11-writing-automated-tests/no-listing-10-result-in-tests/src/lib.rs b/listings/ch11-writing-automated-tests/no-listing-10-result-in-tests/src/lib.rs index 6284f4f291..c31cdcae45 100644 --- a/listings/ch11-writing-automated-tests/no-listing-10-result-in-tests/src/lib.rs +++ b/listings/ch11-writing-automated-tests/no-listing-10-result-in-tests/src/lib.rs @@ -1,11 +1,21 @@ +pub fn add(left: usize, right: usize) -> usize { + left + right +} + #[cfg(test)] mod tests { + use super::*; + + // ANCHOR: here #[test] fn it_works() -> Result<(), String> { - if 2 + 2 == 4 { + let result = add(2, 2); + + if result == 4 { Ok(()) } else { Err(String::from("two plus two does not equal four")) } } + // ANCHOR_END: here } diff --git a/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/output.txt b/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/output.txt index 8d700c7cd9..bc40c96eb8 100644 --- a/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/output.txt +++ b/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/output.txt @@ -4,8 +4,8 @@ $ cargo test Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) running 2 tests -test expensive_test ... ignored -test it_works ... ok +test tests::expensive_test ... ignored +test tests::it_works ... ok test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.00s diff --git a/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/src/lib.rs b/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/src/lib.rs index d54a6095d7..0c8b38defd 100644 --- a/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/src/lib.rs +++ b/listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/src/lib.rs @@ -1,10 +1,22 @@ -#[test] -fn it_works() { - assert_eq!(2 + 2, 4); +pub fn add(left: usize, right: usize) -> usize { + left + right } -#[test] -#[ignore] -fn expensive_test() { - // code that takes an hour to run +// ANCHOR: here +#[cfg(test)] +mod tests { + use super::*; + + #[test] + fn it_works() { + let result = add(2, 2); + assert_eq!(result, 4); + } + + #[test] + #[ignore] + fn expensive_test() { + // code that takes an hour to run + } } +// ANCHOR_END: here diff --git a/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/src/lib.rs b/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/src/lib.rs index c3961b1f62..9ba15d8b22 100644 --- a/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/src/lib.rs +++ b/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/src/lib.rs @@ -1,9 +1,9 @@ -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { internal_adder(a, 2) } -fn internal_adder(a: i32, b: i32) -> i32 { - a + b +fn internal_adder(left: usize, right: usize) -> usize { + left + right } #[cfg(test)] @@ -12,6 +12,7 @@ mod tests { #[test] fn internal() { - assert_eq!(4, internal_adder(2, 2)); + let result = internal_adder(2, 2); + assert_eq!(result, 4); } } diff --git a/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/tests/integration_test.rs b/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/tests/integration_test.rs index e26fa71096..d6b88a7505 100644 --- a/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/tests/integration_test.rs +++ b/listings/ch11-writing-automated-tests/no-listing-12-shared-test-code-problem/tests/integration_test.rs @@ -1,6 +1,7 @@ -use adder; +use adder::add_two; #[test] fn it_adds_two() { - assert_eq!(4, adder::add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } diff --git a/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/src/lib.rs b/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/src/lib.rs index c3961b1f62..9ba15d8b22 100644 --- a/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/src/lib.rs +++ b/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/src/lib.rs @@ -1,9 +1,9 @@ -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { internal_adder(a, 2) } -fn internal_adder(a: i32, b: i32) -> i32 { - a + b +fn internal_adder(left: usize, right: usize) -> usize { + left + right } #[cfg(test)] @@ -12,6 +12,7 @@ mod tests { #[test] fn internal() { - assert_eq!(4, internal_adder(2, 2)); + let result = internal_adder(2, 2); + assert_eq!(result, 4); } } diff --git a/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/tests/integration_test.rs b/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/tests/integration_test.rs index 58b8b7b89b..d18b5b689b 100644 --- a/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/tests/integration_test.rs +++ b/listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/tests/integration_test.rs @@ -1,9 +1,11 @@ -use adder; +use adder::add_two; mod common; #[test] fn it_adds_two() { common::setup(); - assert_eq!(4, adder::add_two(2)); + + let result = add_two(2); + assert_eq!(result, 4); } diff --git a/listings/ch11-writing-automated-tests/output-only-05-single-integration/src/lib.rs b/listings/ch11-writing-automated-tests/output-only-05-single-integration/src/lib.rs index c3961b1f62..9ba15d8b22 100644 --- a/listings/ch11-writing-automated-tests/output-only-05-single-integration/src/lib.rs +++ b/listings/ch11-writing-automated-tests/output-only-05-single-integration/src/lib.rs @@ -1,9 +1,9 @@ -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { internal_adder(a, 2) } -fn internal_adder(a: i32, b: i32) -> i32 { - a + b +fn internal_adder(left: usize, right: usize) -> usize { + left + right } #[cfg(test)] @@ -12,6 +12,7 @@ mod tests { #[test] fn internal() { - assert_eq!(4, internal_adder(2, 2)); + let result = internal_adder(2, 2); + assert_eq!(result, 4); } } diff --git a/listings/ch11-writing-automated-tests/output-only-05-single-integration/tests/integration_test.rs b/listings/ch11-writing-automated-tests/output-only-05-single-integration/tests/integration_test.rs index e26fa71096..d6b88a7505 100644 --- a/listings/ch11-writing-automated-tests/output-only-05-single-integration/tests/integration_test.rs +++ b/listings/ch11-writing-automated-tests/output-only-05-single-integration/tests/integration_test.rs @@ -1,6 +1,7 @@ -use adder; +use adder::add_two; #[test] fn it_adds_two() { - assert_eq!(4, adder::add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } diff --git a/nostarch/chapter11.md b/nostarch/chapter11.md index cf909d70c5..d44a501497 100644 --- a/nostarch/chapter11.md +++ b/nostarch/chapter11.md @@ -85,86 +85,100 @@ $ cd adder The contents of the *src/lib.rs* file in your `adder` library should look like Listing 11-1. + Filename: src/lib.rs + + ``` +pub fn add(left: usize, right: usize) -> usize { + left + right +} + #[cfg(test)] mod tests { - 1 #[test] + use super::*; + + #[test] fn it_works() { - let result = 2 + 2; - 2 assert_eq!(result, 4); + let result = add(2, 2); + assert_eq!(result, 4); } } ``` -Listing 11-1: The test module and function generated automatically by `cargo -new` +Listing 11-1: The code generated automatically by cargo new -For now, let’s ignore the top two lines and focus on the function. Note the -`#[test]` annotation [1]: this attribute indicates this is a test function, so -the test runner knows to treat this function as a test. We might also have -non-test functions in the `tests` module to help set up common scenarios or -perform common operations, so we always need to indicate which functions are -tests. +For now, let’s focus solely on the `it_works` function. Note the `#[test]` +annotation: this attribute indicates this is a test function, so the test +runner knows to treat this function as a test. We might also have non-test +functions in the `tests` module to help set up common scenarios or perform +common operations, so we always need to indicate which functions are tests. -The example function body uses the `assert_eq!` macro [2] to assert that -`result`, which contains the result of adding 2 and 2, equals 4. This assertion -serves as an example of the format for a typical test. Let’s run it to see that -this test passes. +The example function body uses the `assert_eq!` macro to assert that `result`, +which contains the result of adding 2 and 2, equals 4. This assertion serves as +an example of the format for a typical test. Let’s run it to see that this test +passes. The `cargo test` command runs all tests in our project, as shown in Listing 11-2. + ``` $ cargo test Compiling adder v0.1.0 (file:///projects/adder) - Finished test [unoptimized + debuginfo] target(s) in 0.57s - Running unittests src/lib.rs (target/debug/deps/adder- -92948b65e88960b4) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.57s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) -1 running 1 test -2 test tests::it_works ... ok +running 1 test +test tests::it_works ... ok -3 test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s - 4 Doc-tests adder + Doc-tests adder running 0 tests -test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` Listing 11-2: The output from running the automatically generated test -Cargo compiled and ran the test. We see the line `running 1 test` [1]. The next -line shows the name of the generated test function, called `it_works`, and that -the result of running that test is `ok` [2]. The overall summary `test result: -ok.` [3] means that all the tests passed, and the portion that reads `1 passed; -0 failed` totals the number of tests that passed or failed. +Cargo compiled and ran the test. We see the line `running 1 test`. The next +line shows the name of the generated test function, called `tests::it_works`, +and that the result of running that test is `ok`. The overall summary `test result: ok.` means that all the tests passed, and the portion that reads `1 passed; 0 failed` totals the number of tests that passed or failed. It’s possible to mark a test as ignored so it doesn’t run in a particular -instance; we’ll cover that in “Ignoring Some Tests Unless Specifically -Requested” on page XX. Because we haven’t done that here, the summary shows `0 -ignored`. We can also pass an argument to the `cargo test` command to run only -tests whose name matches a string; this is called *filtering* and we’ll cover -it in “Running a Subset of Tests by Name” on page XX. Here we haven’t filtered -the tests being run, so the end of the summary shows `0 filtered out`. +instance; we’ll cover that in the “Ignoring Some Tests Unless Specifically +Requested” section later in this chapter. Because we +haven’t done that here, the summary shows `0 ignored`. The `0 measured` statistic is for benchmark tests that measure performance. Benchmark tests are, as of this writing, only available in nightly Rust. See -the documentation about benchmark tests at -*https://doc.rust-lang.org/unstable-book/library-features/test.html* to learn -more. +the documentation about benchmark tests at *../unstable-book/library-features/test.html* to learn more. + +We can pass an argument to the `cargo test` command to run only tests whose +name matches a string; this is called *filtering* and we’ll cover that in the +“Running a Subset of Tests by Name” section. Here we +haven’t filtered the tests being run, so the end of the summary shows `0 filtered out`. -The next part of the test output starting at `Doc-tests adder` [4] is for the +The next part of the test output starting at `Doc-tests adder` is for the results of any documentation tests. We don’t have any documentation tests yet, but Rust can compile any code examples that appear in our API documentation. This feature helps keep your docs and your code in sync! We’ll discuss how to -write documentation tests in “Documentation Comments as Tests” on page XX. For -now, we’ll ignore the `Doc-tests` output. +write documentation tests in the “Documentation Comments as +Tests” section of Chapter 14. For now, we’ll +ignore the `Doc-tests` output. Let’s start to customize the test to our own needs. First, change the name of the `it_works` function to a different name, such as `exploration`, like so: @@ -172,11 +186,17 @@ the `it_works` function to a different name, such as `exploration`, like so: Filename: src/lib.rs ``` +pub fn add(left: usize, right: usize) -> usize { + left + right +} + #[cfg(test)] mod tests { + use super::*; + #[test] fn exploration() { - let result = 2 + 2; + let result = add(2, 2); assert_eq!(result, 4); } } @@ -186,11 +206,22 @@ Then run `cargo test` again. The output now shows `exploration` instead of `it_works`: ``` +$ cargo test + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.59s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) + running 1 test test tests::exploration ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests adder + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` Now we’ll add another test, but this time we’ll make a test that fails! Tests @@ -200,14 +231,22 @@ marked as failed. In Chapter 9, we talked about how the simplest way to panic is to call the `panic!` macro. Enter the new test as a function named `another`, so your *src/lib.rs* file looks like Listing 11-3. + Filename: src/lib.rs ``` +pub fn add(left: usize, right: usize) -> usize { + left + right +} + #[cfg(test)] mod tests { + use super::*; + #[test] fn exploration() { - assert_eq!(2 + 2, 4); + let result = add(2, 2); + assert_eq!(result, 4); } #[test] @@ -217,52 +256,62 @@ mod tests { } ``` -Listing 11-3: Adding a second test that will fail because we call the `panic!` -macro +Listing 11-3: Adding a second test that will fail because we call the panic! macro Run the tests again using `cargo test`. The output should look like Listing 11-4, which shows that our `exploration` test passed and `another` failed. + ``` +$ cargo test + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.72s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) + running 2 tests +test tests::another ... FAILED test tests::exploration ... ok -1 test tests::another ... FAILED -2 failures: +failures: ---- tests::another stdout ---- -thread 'main' panicked at 'Make this test fail', src/lib.rs:10:9 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'tests::another' panicked at src/lib.rs:17:9: +Make this test fail +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace -3 failures: + +failures: tests::another -4 test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s -error: test failed, to rerun pass '--lib' +error: test failed, to rerun pass `--lib` ``` Listing 11-4: Test results when one test passes and one test fails -Instead of `ok`, the line `test tests::another` shows `FAILED` [1]. Two new -sections appear between the individual results and the summary: the first [2] + + +Instead of `ok`, the line `test tests::another` shows `FAILED`. Two new +sections appear between the individual results and the summary: the first displays the detailed reason for each test failure. In this case, we get the details that `another` failed because it `panicked at 'Make this test fail'` on -line 10 in the *src/lib.rs* file. The next section [3] lists just the names of -all the failing tests, which is useful when there are lots of tests and lots of +line 17 in the *src/lib.rs* file. The next section lists just the names of all +the failing tests, which is useful when there are lots of tests and lots of detailed failing test output. We can use the name of a failing test to run just that test to more easily debug it; we’ll talk more about ways to run tests in -“Controlling How Tests Are Run” on page XX. +the “Controlling How Tests Are Run” section. -The summary line displays at the end [4]: overall, our test result is `FAILED`. -We had one test pass and one test fail. +The summary line displays at the end: overall, our test result is `FAILED`. We +had one test pass and one test fail. Now that you’ve seen what the test results look like in different scenarios, let’s look at some macros other than `panic!` that are useful in tests. -### Checking Results with the assert! Macro +### Checking Results with the `assert!` Macro The `assert!` macro, provided by the standard library, is useful when you want to ensure that some condition in a test evaluates to `true`. We give the @@ -271,9 +320,10 @@ to ensure that some condition in a test evaluates to `true`. We give the `assert!` macro calls `panic!` to cause the test to fail. Using the `assert!` macro helps us check that our code is functioning in the way we intend. -In Listing 5-15, we used a `Rectangle` struct and a `can_hold` method, which -are repeated here in Listing 11-5. Let’s put this code in the *src/lib.rs* -file, then write some tests for it using the `assert!` macro. +In Chapter 5, Listing 5-15, we used a `Rectangle` struct and a `can_hold` +method, which are repeated here in Listing 11-5. Let’s put this code in the +*src/lib.rs* file, then write some tests for it using the `assert!` macro. + Filename: src/lib.rs @@ -291,8 +341,7 @@ impl Rectangle { } ``` -Listing 11-5: Using the `Rectangle` struct and its `can_hold` method from -Chapter 5 +Listing 11-5: The Rectangle struct and its can_hold method from Chapter 5 The `can_hold` method returns a Boolean, which means it’s a perfect use case for the `assert!` macro. In Listing 11-6, we write a test that exercises the @@ -300,16 +349,17 @@ for the `assert!` macro. In Listing 11-6, we write a test that exercises the a height of 7 and asserting that it can hold another `Rectangle` instance that has a width of 5 and a height of 1. + Filename: src/lib.rs ``` #[cfg(test)] mod tests { - 1 use super::*; + use super::*; #[test] - 2 fn larger_can_hold_smaller() { - 3 let larger = Rectangle { + fn larger_can_hold_smaller() { + let larger = Rectangle { width: 8, height: 7, }; @@ -318,34 +368,44 @@ mod tests { height: 1, }; - 4 assert!(larger.can_hold(&smaller)); + assert!(larger.can_hold(&smaller)); } } ``` -Listing 11-6: A test for `can_hold` that checks whether a larger rectangle can -indeed hold a smaller rectangle +Listing 11-6: A test for can_hold that checks whether a larger rectangle can indeed hold a smaller rectangle -Note that we’ve added a new line inside the `tests` module: `use super::*;` -[1]. The `tests` module is a regular module that follows the usual visibility -rules we covered in “Paths for Referring to an Item in the Module Tree” on page -XX. Because the `tests` module is an inner module, we need to bring the code -under test in the outer module into the scope of the inner module. We use a -glob here, so anything we define in the outer module is available to this +Note the `use super::*;` line inside the `tests` module. The `tests` module is +a regular module that follows the usual visibility rules we covered in Chapter +7 in the “Paths for Referring to an Item in the Module +Tree” +section. Because the `tests` module is an inner module, we need to bring the +code under test in the outer module into the scope of the inner module. We use +a glob here, so anything we define in the outer module is available to this `tests` module. -We’ve named our test `larger_can_hold_smaller` [2], and we’ve created the two -`Rectangle` instances that we need [3]. Then we called the `assert!` macro and -passed it the result of calling `larger.can_hold(&smaller)` [4]. This -expression is supposed to return `true`, so our test should pass. Let’s find -out! +We’ve named our test `larger_can_hold_smaller`, and we’ve created the two +`Rectangle` instances that we need. Then we called the `assert!` macro and +passed it the result of calling `larger.can_hold(&smaller)`. This expression is +supposed to return `true`, so our test should pass. Let’s find out! ``` +$ cargo test + Compiling rectangle v0.1.0 (file:///projects/rectangle) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s + Running unittests src/lib.rs (target/debug/deps/rectangle-6584c4561e48942e) + running 1 test test tests::larger_can_hold_smaller ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests rectangle + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` It does pass! Let’s add another test, this time asserting that a smaller @@ -360,7 +420,7 @@ mod tests { #[test] fn larger_can_hold_smaller() { - --snip-- + // --snip-- } #[test] @@ -384,12 +444,23 @@ we need to negate that result before we pass it to the `assert!` macro. As a result, our test will pass if `can_hold` returns `false`: ``` +$ cargo test + Compiling rectangle v0.1.0 (file:///projects/rectangle) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s + Running unittests src/lib.rs (target/debug/deps/rectangle-6584c4561e48942e) + running 2 tests test tests::larger_can_hold_smaller ... ok test tests::smaller_cannot_hold_larger ... ok -test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests rectangle + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` Two tests that pass! Now let’s see what happens to our test results when we @@ -398,8 +469,7 @@ method by replacing the greater-than sign with a less-than sign when it compares the widths: ``` ---snip-- - +// --snip-- impl Rectangle { fn can_hold(&self, other: &Rectangle) -> bool { self.width < other.width && self.height > other.height @@ -410,31 +480,36 @@ impl Rectangle { Running the tests now produces the following: ``` +$ cargo test + Compiling rectangle v0.1.0 (file:///projects/rectangle) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s + Running unittests src/lib.rs (target/debug/deps/rectangle-6584c4561e48942e) + running 2 tests -test tests::smaller_cannot_hold_larger ... ok test tests::larger_can_hold_smaller ... FAILED +test tests::smaller_cannot_hold_larger ... ok failures: ---- tests::larger_can_hold_smaller stdout ---- -thread 'main' panicked at 'assertion failed: -larger.can_hold(&smaller)', src/lib.rs:28:9 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'tests::larger_can_hold_smaller' panicked at src/lib.rs:28:9: +assertion failed: larger.can_hold(&smaller) +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: tests::larger_can_hold_smaller -test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` Our tests caught the bug! Because `larger.width` is `8` and `smaller.width` is `5`, the comparison of the widths in `can_hold` now returns `false`: 8 is not less than 5. -### Testing Equality with the assert_eq! and assert_ne! Macros +### Testing Equality with the `assert_eq!` and `assert_ne!` Macros A common way to verify functionality is to test for equality between the result of the code under test and the value you expect the code to return. You could @@ -450,10 +525,11 @@ expression, without printing the values that led to the `false` value. In Listing 11-7, we write a function named `add_two` that adds `2` to its parameter, then we test this function using the `assert_eq!` macro. + Filename: src/lib.rs ``` -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { a + 2 } @@ -463,32 +539,45 @@ mod tests { #[test] fn it_adds_two() { - assert_eq!(4, add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } } ``` -Listing 11-7: Testing the function `add_two` using the `assert_eq!` macro +Listing 11-7: Testing the function add_two using the assert_eq! macro Let’s check that it passes! ``` +$ cargo test + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.58s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) + running 1 test test tests::it_adds_two ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests adder + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` -We pass `4` as the argument to `assert_eq!`, which is equal to the result of -calling `add_two(2)`. The line for this test is `test tests::it_adds_two ... -ok`, and the `ok` text indicates that our test passed! +We create a variable named `result` that holds the result of calling +`add_two(2)`. Then we pass `result` and `4` as the arguments to `assert_eq!`. +The output line for this test is `test tests::it_adds_two ... ok`, and the `ok` +text indicates that our test passed! Let’s introduce a bug into our code to see what `assert_eq!` looks like when it fails. Change the implementation of the `add_two` function to instead add `3`: ``` -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { a + 3 } ``` @@ -496,39 +585,46 @@ pub fn add_two(a: i32) -> i32 { Run the tests again: ``` +$ cargo test + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [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 ---- -1 thread 'main' panicked at 'assertion failed: `(left == right)` -2 left: `4`, -3 right: `5`', src/lib.rs:11:9 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'tests::it_adds_two' panicked at src/lib.rs:12:9: +assertion `left == right` failed + left: 5 + right: 4 +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 +test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` Our test caught the bug! The `it_adds_two` test failed, and the message tells -us that the assertion that failed was `assertion failed: `(left == right)`` [1] -and what the `left` [2] and `right` [3] values are. This message helps us start -debugging: the `left` argument was `4` but the `right` argument, where we had -`add_two(2)`, was `5`. You can imagine that this would be especially helpful -when we have a lot of tests going on. +us ``assertion `left == right` failed`` and what the `left` and `right` values +are. This message helps us start debugging: the `left` argument, where we had +the result of calling `add_two(2)`, was `5` but the `right` argument was `4`. +You can imagine that this would be especially helpful when we have a lot of +tests going on. Note that in some languages and test frameworks, the parameters to equality assertion functions are called `expected` and `actual`, and the order in which we specify the arguments matters. However, in Rust, they’re called `left` and `right`, and the order in which we specify the value we expect and the value the code produces doesn’t matter. We could write the assertion in this test as -`assert_eq!(add_two(2), 4)`, which would result in the same failure message -that displays `assertion failed: `(left == right)``. +`assert_eq!(4, result)`, which would produce the same failure message +that displays `` assertion failed: `(left == right)` ``. The `assert_ne!` macro will pass if the two values we give it are not equal and fail if they’re equal. This macro is most useful for cases when we’re not sure @@ -546,20 +642,23 @@ the standard library types implement these traits. For structs and enums that you define yourself, you’ll need to implement `PartialEq` to assert equality of those types. You’ll also need to implement `Debug` to print the values when the assertion fails. Because both traits are derivable traits, as mentioned in -Listing 5-12, this is usually as straightforward as adding the +Listing 5-12 in Chapter 5, this is usually as straightforward as adding the `#[derive(PartialEq, Debug)]` annotation to your struct or enum definition. See -Appendix C for more details about these and other derivable traits. +Appendix C, “Derivable Traits,” for more +details about these and other derivable traits. ### Adding Custom Failure Messages You can also add a custom message to be printed with the failure message as optional arguments to the `assert!`, `assert_eq!`, and `assert_ne!` macros. Any arguments specified after the required arguments are passed along to the -`format!` macro (discussed in “Concatenation with the + Operator or the format! -Macro” on page XX), so you can pass a format string that contains `{}` -placeholders and values to go in those placeholders. Custom messages are useful -for documenting what an assertion means; when a test fails, you’ll have a -better idea of what the problem is with the code. +`format!` macro (discussed in Chapter 8 in the “Concatenation with the `+` +Operator or the `format!` +Macro” +section), so you can pass a format string that contains `{}` placeholders and +values to go in those placeholders. Custom messages are useful for documenting +what an assertion means; when a test fails, you’ll have a better idea of what +the problem is with the code. For example, let’s say we have a function that greets people by name and we want to test that the name we pass into the function appears in the output: @@ -602,20 +701,28 @@ pub fn greeting(name: &str) -> String { Running this test produces the following: ``` +$ cargo test + Compiling greeter v0.1.0 (file:///projects/greeter) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.91s + Running unittests src/lib.rs (target/debug/deps/greeter-170b942eb5bf5e3a) + running 1 test test tests::greeting_contains_name ... FAILED failures: ---- tests::greeting_contains_name stdout ---- -thread 'main' panicked at 'assertion failed: -result.contains(\"Carol\")', src/lib.rs:12:9 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'tests::greeting_contains_name' panicked at src/lib.rs:12:9: +assertion failed: result.contains("Carol") +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: tests::greeting_contains_name + +test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` This result just indicates that the assertion failed and which line the @@ -625,37 +732,54 @@ string with a placeholder filled in with the actual value we got from the `greeting` function: ``` -#[test] -fn greeting_contains_name() { - let result = greeting("Carol"); - assert!( - result.contains("Carol"), - "Greeting did not contain name, value was `{result}`" - ); -} + #[test] + fn greeting_contains_name() { + let result = greeting("Carol"); + assert!( + result.contains("Carol"), + "Greeting did not contain name, value was `{result}`" + ); + } ``` Now when we run the test, we’ll get a more informative error message: ``` +$ cargo test + Compiling greeter v0.1.0 (file:///projects/greeter) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.93s + Running unittests src/lib.rs (target/debug/deps/greeter-170b942eb5bf5e3a) + +running 1 test +test tests::greeting_contains_name ... FAILED + +failures: + ---- tests::greeting_contains_name stdout ---- -thread 'main' panicked at 'Greeting did not contain name, value -was `Hello!`', src/lib.rs:12:9 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'tests::greeting_contains_name' panicked at src/lib.rs:12:9: +Greeting did not contain name, value was `Hello!` +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace + + +failures: + tests::greeting_contains_name + +test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` We can see the value we actually got in the test output, which would help us debug what happened instead of what we were expecting to happen. -### Checking for Panics with should_panic +### Checking for Panics with `should_panic` In addition to checking return values, it’s important to check that our code handles error conditions as we expect. For example, consider the `Guess` type -that we created in Listing 9-13. Other code that uses `Guess` depends on the -guarantee that `Guess` instances will contain only values between 1 and 100. We -can write a test that ensures that attempting to create a `Guess` instance with -a value outside that range panics. +that we created in Chapter 9, Listing 9-13. Other code that uses `Guess` +depends on the guarantee that `Guess` instances will contain only values +between 1 and 100. We can write a test that ensures that attempting to create a +`Guess` instance with a value outside that range panics. We do this by adding the attribute `should_panic` to our test function. The test passes if the code inside the function panics; the test fails if the code @@ -664,8 +788,10 @@ inside the function doesn’t panic. Listing 11-8 shows a test that checks that the error conditions of `Guess::new` happen when we expect them to. + +Filename: src/lib.rs + ``` -// src/lib.rs pub struct Guess { value: i32, } @@ -673,10 +799,7 @@ pub struct Guess { impl Guess { pub fn new(value: i32) -> Guess { if value < 1 || value > 100 { - panic!( - "Guess value must be between 1 and 100, got {}.", - value - ); + panic!("Guess value must be between 1 and 100, got {value}."); } Guess { value } @@ -695,34 +818,40 @@ mod tests { } ``` -Listing 11-8: Testing that a condition will cause a panic! +Listing 11-8: Testing that a condition will cause a panic! We place the `#[should_panic]` attribute after the `#[test]` attribute and before the test function it applies to. Let’s look at the result when this test passes: ``` +$ cargo test + Compiling guessing_game v0.1.0 (file:///projects/guessing_game) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.58s + Running unittests src/lib.rs (target/debug/deps/guessing_game-57d70c3acb738f4d) + running 1 test test tests::greater_than_100 - should panic ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests guessing_game + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` Looks good! Now let’s introduce a bug in our code by removing the condition that the `new` function will panic if the value is greater than 100: ``` -// src/lib.rs ---snip-- - +// --snip-- impl Guess { pub fn new(value: i32) -> Guess { if value < 1 { - panic!( - "Guess value must be between 1 and 100, got {}.", - value - ); + panic!("Guess value must be between 1 and 100, got {value}."); } Guess { value } @@ -733,6 +862,11 @@ impl Guess { When we run the test in Listing 11-8, it will fail: ``` +$ cargo test + Compiling guessing_game v0.1.0 (file:///projects/guessing_game) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.62s + Running unittests src/lib.rs (target/debug/deps/guessing_game-57d70c3acb738f4d) + running 1 test test tests::greater_than_100 - should panic ... FAILED @@ -744,8 +878,9 @@ note: test did not panic as expected failures: tests::greater_than_100 -test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` We don’t get a very helpful message in this case, but when we look at the test @@ -761,21 +896,21 @@ consider the modified code for `Guess` in Listing 11-9 where the `new` function panics with different messages depending on whether the value is too small or too large. + +Filename: src/lib.rs + ``` -// src/lib.rs ---snip-- +// --snip-- impl Guess { pub fn new(value: i32) -> Guess { if value < 1 { panic!( - "Guess value must be greater than or equal to 1, got {}.", - value + "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 must be less than or equal to 100, got {value}." ); } @@ -795,14 +930,12 @@ mod tests { } ``` -Listing 11-9: Testing for a `panic!` with a panic message containing a -specified substring +Listing 11-9: Testing for a panic! with a panic message containing a specified substring This test will pass because the value we put in the `should_panic` attribute’s `expected` parameter is a substring of the message that the `Guess::new` function panics with. We could have specified the entire panic message that we -expect, which in this case would be `Guess value must be less than or equal to -100, got 200`. What you choose to specify depends on how much of the panic +expect, which in this case would be `Guess value must be less than or equal to 100, got 200`. What you choose to specify depends on how much of the panic message is unique or dynamic and how precise you want your test to be. In this case, a substring of the panic message is enough to ensure that the code in the test function executes the `else if value > 100` case. @@ -812,72 +945,66 @@ fails, let’s again introduce a bug into our code by swapping the bodies of the `if value < 1` and the `else if value > 100` blocks: ``` -// src/lib.rs ---snip-- -if value < 1 { - panic!( - "Guess value must be less than or equal to 100, got {}.", - value - ); -} else if value > 100 { - panic!( - "Guess value must be greater than or equal to 1, got {}.", - value - ); -} ---snip-- + if value < 1 { + panic!( + "Guess value must be less than or equal to 100, got {value}." + ); + } else if value > 100 { + panic!( + "Guess value must be greater than or equal to 1, got {value}." + ); + } ``` This time when we run the `should_panic` test, it will fail: ``` +$ cargo test + Compiling guessing_game v0.1.0 (file:///projects/guessing_game) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s + Running unittests src/lib.rs (target/debug/deps/guessing_game-57d70c3acb738f4d) + running 1 test test tests::greater_than_100 - should panic ... FAILED failures: ---- tests::greater_than_100 stdout ---- -thread 'main' panicked at 'Guess value must be greater than or equal to 1, got -200.', src/lib.rs:13:13 +thread 'tests::greater_than_100' panicked at src/lib.rs:12:13: +Guess value must be greater than or equal to 1, got 200. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace note: panic did not contain expected string - panic message: `"Guess value must be greater than or equal to 1, got -200."`, + panic message: `"Guess value must be greater than or equal to 1, got 200."`, expected substring: `"less than or equal to 100"` failures: tests::greater_than_100 -test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; -finished in 0.00s +test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` The failure message indicates that this test did indeed panic as we expected, -but the panic message did not include the expected string `'Guess value must be -less than or equal to 100'`. The panic message that we did get in this case was -`Guess value must be greater than or equal to 1, got 200`. Now we can start -figuring out where our bug is! +but the panic message did not include the expected string `less than or equal to 100`. The panic message that we did get in this case was `Guess value must be greater than or equal to 1, got 200.` Now we can start figuring out where +our bug is! -### Using Result in Tests +### Using `Result` in Tests Our tests so far all panic when they fail. We can also write tests that use -`Result`! Here’s the test from Listing 11-1, rewritten to use `Result` and return an `Err` instead of panicking: - -Filename: src/lib.rs +`Result`! Here’s the test from Listing 11-1, rewritten to use `Result` and return an `Err` instead of panicking: ``` -#[cfg(test)] -mod tests { #[test] fn it_works() -> Result<(), String> { - if 2 + 2 == 4 { + let result = add(2, 2); + + if result == 4 { Ok(()) } else { Err(String::from("two plus two does not equal four")) } } -} ``` The `it_works` function now has the `Result<(), String>` return type. In the @@ -889,14 +1016,12 @@ Writing tests so they return a `Result` enables you to use the question mark operator in the body of tests, which can be a convenient way to write tests that should fail if any operation within them returns an `Err` variant. -You can’t use the `#[should_panic]` annotation on tests that use `Result`. To assert that an operation returns an `Err` variant, *don’t* use the +You can’t use the `#[should_panic]` annotation on tests that use `Result`. To assert that an operation returns an `Err` variant, *don’t* use the question mark operator on the `Result` value. Instead, use `assert!(value.is_err())`. Now that you know several ways to write tests, let’s look at what is happening -when we run our tests and explore the different options we can use with `cargo -test`. +when we run our tests and explore the different options we can use with `cargo test`. ## Controlling How Tests Are Run @@ -958,6 +1083,7 @@ printed to standard output with the rest of the failure message. As an example, Listing 11-10 has a silly function that prints the value of its parameter and returns 10, as well as a test that passes and a test that fails. + Filename: src/lib.rs ``` @@ -973,48 +1099,54 @@ mod tests { #[test] fn this_test_will_pass() { let value = prints_and_returns_10(4); - assert_eq!(10, value); + assert_eq!(value, 10); } #[test] fn this_test_will_fail() { let value = prints_and_returns_10(8); - assert_eq!(5, value); + assert_eq!(value, 5); } } ``` -Listing 11-10: Tests for a function that calls `println!` +Listing 11-10: Tests for a function that calls println! When we run these tests with `cargo test`, we’ll see the following output: ``` +$ cargo test + Compiling silly-function v0.1.0 (file:///projects/silly-function) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.58s + Running unittests src/lib.rs (target/debug/deps/silly_function-160869f38cff9166) + running 2 tests -test tests::this_test_will_pass ... ok test tests::this_test_will_fail ... FAILED +test tests::this_test_will_pass ... ok failures: ---- tests::this_test_will_fail stdout ---- -1 I got the value 8 -thread 'main' panicked at 'assertion failed: `(left == right)` - left: `5`, - right: `10`', src/lib.rs:19:9 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +I got the value 8 +thread 'tests::this_test_will_fail' panicked at src/lib.rs:19:9: +assertion `left == right` failed + left: 10 + right: 5 +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace + failures: tests::this_test_will_fail -test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` Note that nowhere in this output do we see `I got the value 4`, which is printed when the test that passes runs. That output has been captured. The -output from the test that failed, `I got the value 8` [1], appears in the -section of the test summary output, which also shows the cause of the test -failure. +output from the test that failed, `I got the value 8`, appears in the section +of the test summary output, which also shows the cause of the test failure. If we want to see printed values for passing tests as well, we can tell Rust to also show the output of successful tests with `--show-output`: @@ -1027,9 +1159,14 @@ When we run the tests in Listing 11-10 again with the `--show-output` flag, we see the following output: ``` +$ cargo test -- --show-output + Compiling silly-function v0.1.0 (file:///projects/silly-function) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.60s + Running unittests src/lib.rs (target/debug/deps/silly_function-160869f38cff9166) + running 2 tests -test tests::this_test_will_pass ... ok test tests::this_test_will_fail ... FAILED +test tests::this_test_will_pass ... ok successes: @@ -1044,17 +1181,19 @@ failures: ---- tests::this_test_will_fail stdout ---- I got the value 8 -thread 'main' panicked at 'assertion failed: `(left == right)` - left: `5`, - right: `10`', src/lib.rs:19:9 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'tests::this_test_will_fail' panicked at src/lib.rs:19:9: +assertion `left == right` failed + left: 5 + right: 10 +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace + failures: tests::this_test_will_fail -test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + +error: test failed, to rerun pass `--lib` ``` ### Running a Subset of Tests by Name @@ -1067,10 +1206,11 @@ or names of the test(s) you want to run as an argument. To demonstrate how to run a subset of tests, we’ll first create three tests for our `add_two` function, as shown in Listing 11-11, and choose which ones to run. + Filename: src/lib.rs ``` -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { a + 2 } @@ -1080,17 +1220,20 @@ mod tests { #[test] fn add_two_and_two() { - assert_eq!(4, add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } #[test] fn add_three_and_two() { - assert_eq!(5, add_two(3)); + let result = add_two(3); + assert_eq!(result, 5); } #[test] fn one_hundred() { - assert_eq!(102, add_two(100)); + let result = add_two(100); + assert_eq!(result, 102); } } ``` @@ -1101,13 +1244,24 @@ If we run the tests without passing any arguments, as we saw earlier, all the tests will run in parallel: ``` +$ cargo test + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.62s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) + running 3 tests test tests::add_three_and_two ... ok test tests::add_two_and_two ... ok test tests::one_hundred ... ok -test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests adder + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` #### Running Single Tests @@ -1117,15 +1271,14 @@ We can pass the name of any test function to `cargo test` to run only that test: ``` $ cargo test one_hundred Compiling adder v0.1.0 (file:///projects/adder) - Finished test [unoptimized + debuginfo] target(s) in 0.69s - Running unittests src/lib.rs (target/debug/deps/adder- -92948b65e88960b4) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.69s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) running 1 test test tests::one_hundred ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out; finished in 0.00s + ``` Only the test with the name `one_hundred` ran; the other two tests didn’t match @@ -1144,16 +1297,15 @@ run those two by running `cargo test add`: ``` $ cargo test add 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) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.61s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) running 2 tests test tests::add_three_and_two ... ok test tests::add_two_and_two ... ok -test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 1 -filtered out; finished in 0.00s +test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s + ``` This command ran all tests with `add` in the name and filtered out the test @@ -1172,16 +1324,21 @@ here: Filename: src/lib.rs ``` -#[test] -fn it_works() { - let result = 2 + 2; - assert_eq!(result, 4); -} +#[cfg(test)] +mod tests { + use super::*; -#[test] -#[ignore] -fn expensive_test() { - // code that takes an hour to run + #[test] + fn it_works() { + let result = add(2, 2); + assert_eq!(result, 4); + } + + #[test] + #[ignore] + fn expensive_test() { + // code that takes an hour to run + } } ``` @@ -1191,16 +1348,21 @@ Now when we run our tests, `it_works` runs, but `expensive_test` doesn’t: ``` $ cargo test Compiling adder v0.1.0 (file:///projects/adder) - Finished test [unoptimized + debuginfo] target(s) in 0.60s - Running unittests src/lib.rs (target/debug/deps/adder- -92948b65e88960b4) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.60s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) running 2 tests -test expensive_test ... ignored -test it_works ... ok +test tests::expensive_test ... ignored +test tests::it_works ... ok + +test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests adder + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s -test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 -filtered out; finished in 0.00s ``` The `expensive_test` function is listed as `ignored`. If we want to run only @@ -1208,15 +1370,21 @@ the ignored tests, we can use `cargo test -- --ignored`: ``` $ cargo test -- --ignored - Finished test [unoptimized + debuginfo] target(s) in 0.61s - Running unittests src/lib.rs (target/debug/deps/adder- -92948b65e88960b4) + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.61s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) running 1 test test expensive_test ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s + + Doc-tests adder + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` By controlling which tests run, you can make sure your `cargo test` results @@ -1248,11 +1416,10 @@ code that they’re testing. The convention is to create a module named `tests` in each file to contain the test functions and to annotate the module with `cfg(test)`. -#### The Tests Module and #[cfg(test)] +#### The Tests Module and `#[cfg(test)]` The `#[cfg(test)]` annotation on the `tests` module tells Rust to compile and -run the test code only when you run `cargo test`, not when you run `cargo -build`. This saves compile time when you only want to build the library and +run the test code only when you run `cargo test`, not when you run `cargo build`. This saves compile time when you only want to build the library and saves space in the resultant compiled artifact because the tests are not included. You’ll see that because integration tests go in a different directory, they don’t need the `#[cfg(test)]` annotation. However, because unit @@ -1265,24 +1432,29 @@ this chapter, Cargo generated this code for us: Filename: src/lib.rs ``` +pub fn add(left: usize, right: usize) -> usize { + left + right +} + #[cfg(test)] mod tests { + use super::*; + #[test] fn it_works() { - let result = 2 + 2; + let result = add(2, 2); assert_eq!(result, 4); } } ``` -This code is the automatically generated `tests` module. The attribute `cfg` -stands for *configuration* and tells Rust that the following item should only -be included given a certain configuration option. In this case, the -configuration option is `test`, which is provided by Rust for compiling and -running tests. By using the `cfg` attribute, Cargo compiles our test code only -if we actively run the tests with `cargo test`. This includes any helper -functions that might be within this module, in addition to the functions -annotated with `#[test]`. +On the automatically generated `tests` module, the attribute `cfg` stands for +*configuration* and tells Rust that the following item should only be included +given a certain configuration option. In this case, the configuration option is +`test`, which is provided by Rust for compiling and running tests. By using the +`cfg` attribute, Cargo compiles our test code only if we actively run the tests +with `cargo test`. This includes any helper functions that might be within this +module, in addition to the functions annotated with `#[test]`. #### Testing Private Functions @@ -1292,15 +1464,16 @@ impossible to test private functions. Regardless of which testing ideology you adhere to, Rust’s privacy rules do allow you to test private functions. Consider the code in Listing 11-12 with the private function `internal_adder`. + Filename: src/lib.rs ``` -pub fn add_two(a: i32) -> i32 { +pub fn add_two(a: usize) -> usize { internal_adder(a, 2) } -fn internal_adder(a: i32, b: i32) -> i32 { - a + b +fn internal_adder(left: usize, right: usize) -> usize { + left + right } #[cfg(test)] @@ -1309,7 +1482,8 @@ mod tests { #[test] fn internal() { - assert_eq!(4, internal_adder(2, 2)); + let result = internal_adder(2, 2); + assert_eq!(result, 4); } } ``` @@ -1318,11 +1492,12 @@ Listing 11-12: Testing a private function Note that the `internal_adder` function is not marked as `pub`. Tests are just Rust code, and the `tests` module is just another module. As we discussed in -“Paths for Referring to an Item in the Module Tree” on page XX, items in child -modules can use the items in their ancestor modules. In this test, we bring all -of the `test` module’s parent’s items into scope with `use super::*`, and then -the test can call `internal_adder`. If you don’t think private functions should -be tested, there’s nothing in Rust that will compel you to do so. +the “Paths for Referring to an Item in the Module Tree” +section, items in child modules can use the items in their ancestor modules. In +this test, we bring all of the `tests` module’s parent’s items into scope with +`use super::*`, and then the test can call `internal_adder`. If you don’t think +private functions should be tested, there’s nothing in Rust that will compel +you to do so. ### Integration Tests @@ -1334,7 +1509,7 @@ work correctly on their own could have problems when integrated, so test coverage of the integrated code is important as well. To create integration tests, you first need a *tests* directory. -#### The tests Directory +#### The *tests* Directory We create a *tests* directory at the top level of our project directory, next to *src*. Cargo knows to look for integration test files in this directory. We @@ -1350,29 +1525,30 @@ adder ├── Cargo.lock ├── Cargo.toml ├── src -│ └── lib.rs +│   └── lib.rs └── tests └── integration_test.rs ``` Enter the code in Listing 11-13 into the *tests/integration_test.rs* file. + Filename: tests/integration_test.rs ``` -use adder; +use adder::add_two; #[test] fn it_adds_two() { - assert_eq!(4, adder::add_two(2)); + let result = add_two(2); + assert_eq!(result, 4); } ``` -Listing 11-13: An integration test of a function in the `adder` crate +Listing 11-13: An integration test of a function in the adder crate Each file in the *tests* directory is a separate crate, so we need to bring our -library into each test crate’s scope. For that reason we add `use adder;` at -the top of the code, which we didn’t need in the unit tests. +library into each test crate’s scope. For that reason we add `use adder::add_two;` at the top of the code, which we didn’t need in the unit tests. We don’t need to annotate any code in *tests/integration_test.rs* with `#[cfg(test)]`. Cargo treats the *tests* directory specially and compiles files @@ -1381,31 +1557,27 @@ in this directory only when we run `cargo test`. Run `cargo test` now: ``` $ cargo test Compiling adder v0.1.0 (file:///projects/adder) - Finished test [unoptimized + debuginfo] target(s) in 1.31s - Running unittests src/lib.rs (target/debug/deps/adder- -1082c4b063a8fbe6) + Finished `test` profile [unoptimized + debuginfo] target(s) in 1.31s + Running unittests src/lib.rs (target/debug/deps/adder-1082c4b063a8fbe6) -1 running 1 test +running 1 test test tests::internal ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s - 2 Running tests/integration_test.rs -(target/debug/deps/integration_test-1082c4b063a8fbe6) + Running tests/integration_test.rs (target/debug/deps/integration_test-1082c4b063a8fbe6) running 1 test -3 test it_adds_two ... ok +test it_adds_two ... ok -4 test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s Doc-tests adder running 0 tests -test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` The three sections of output include the unit tests, the integration test, and @@ -1414,14 +1586,13 @@ will not be run. For example, if a unit test fails, there won’t be any output for integration and doc tests because those tests will only be run if all unit tests are passing. -The first section for the unit tests [1] is the same as we’ve been seeing: one -line for each unit test (one named `internal` that we added in Listing 11-12) -and then a summary line for the unit tests. +The first section for the unit tests is the same as we’ve been seeing: one line +for each unit test (one named `internal` that we added in Listing 11-12) and +then a summary line for the unit tests. -The integration tests section starts with the line `Running -tests/integration_test.rs` [2]. Next, there is a line for each test function in -that integration test [3] and a summary line for the results of the integration -test [4] just before the `Doc-tests adder` section starts. +The integration tests section starts with the line `Running tests/integration_test.rs`. Next, there is a line for each test function in +that integration test and a summary line for the results of the integration +test just before the `Doc-tests adder` section starts. Each integration test file has its own section, so if we add more files in the *tests* directory, there will be more integration test sections. @@ -1433,15 +1604,15 @@ followed by the name of the file: ``` $ cargo test --test integration_test - Finished test [unoptimized + debuginfo] target(s) in 0.64s - Running tests/integration_test.rs -(target/debug/deps/integration_test-82e7799c1bc62298) + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.64s + Running tests/integration_test.rs (target/debug/deps/integration_test-82e7799c1bc62298) running 1 test test it_adds_two ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` This command runs only the tests in the *tests/integration_test.rs* file. @@ -1459,11 +1630,11 @@ regarding how to separate code into modules and files. The different behavior of *tests* directory files is most noticeable when you have a set of helper functions to use in multiple integration test files and -you try to follow the steps in “Separating Modules into Different Files” on -page XX to extract them into a common module. For example, if we create -*tests/common.rs* and place a function named `setup` in it, we can add some -code to `setup` that we want to call from multiple test functions in multiple -test files: +you try to follow the steps in the “Separating Modules into Different +Files” section of Chapter 7 to +extract them into a common module. For example, if we create *tests/common.rs* +and place a function named `setup` in it, we can add some code to `setup` that +we want to call from multiple test functions in multiple test files: Filename: tests/common.rs @@ -1478,35 +1649,35 @@ When we run the tests again, we’ll see a new section in the test output for th did we call the `setup` function from anywhere: ``` +$ cargo test + Compiling adder v0.1.0 (file:///projects/adder) + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.89s + Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4) + running 1 test test tests::internal ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s - Running tests/common.rs (target/debug/deps/common- -92948b65e88960b4) + Running tests/common.rs (target/debug/deps/common-92948b65e88960b4) running 0 tests -test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s - Running tests/integration_test.rs -(target/debug/deps/integration_test-92948b65e88960b4) + Running tests/integration_test.rs (target/debug/deps/integration_test-92948b65e88960b4) running 1 test test it_adds_two ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s Doc-tests adder running 0 tests -test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` Having `common` appear in the test results with `running 0 tests` displayed for @@ -1519,20 +1690,21 @@ project directory now looks like this: ├── Cargo.lock ├── Cargo.toml ├── src -│ └── lib.rs +│   └── lib.rs └── tests ├── common - │ └── mod.rs + │   └── mod.rs └── integration_test.rs ``` This is the older naming convention that Rust also understands that we -mentioned in “Alternate File Paths” on page XX. Naming the file this way tells -Rust not to treat the `common` module as an integration test file. When we move -the `setup` function code into *tests/common/mod.rs* and delete the -*tests/common.rs* file, the section in the test output will no longer appear. -Files in subdirectories of the *tests* directory don’t get compiled as separate -crates or have sections in the test output. +mentioned in the “Alternate File Paths” section of +Chapter 7. Naming the file this way tells Rust not to treat the `common` module +as an integration test file. When we move the `setup` function code into +*tests/common/mod.rs* and delete the *tests/common.rs* file, the section in the +test output will no longer appear. Files in subdirectories of the *tests* +directory don’t get compiled as separate crates or have sections in the test +output. After we’ve created *tests/common/mod.rs*, we can use it from any of the integration test files as a module. Here’s an example of calling the `setup` @@ -1541,14 +1713,16 @@ function from the `it_adds_two` test in *tests/integration_test.rs*: Filename: tests/integration_test.rs ``` -use adder; +use adder::add_two; mod common; #[test] fn it_adds_two() { common::setup(); - assert_eq!(4, adder::add_two(2)); + + let result = add_two(2); + assert_eq!(result, 4); } ``` @@ -1584,4 +1758,3 @@ reduce logic bugs having to do with how your code is expected to behave. Let’s combine the knowledge you learned in this chapter and in previous chapters to work on a project! - diff --git a/packages/tools/src/bin/link2print.rs b/packages/tools/src/bin/link2print.rs index 09edd84bdb..7d11278876 100644 --- a/packages/tools/src/bin/link2print.rs +++ b/packages/tools/src/bin/link2print.rs @@ -60,8 +60,12 @@ fn parse_links((buffer, ref_map): (String, HashMap)) -> String { name.starts_with("profile") || name.starts_with("test") || name.starts_with("no_mangle") || + name.starts_with("cfg") || + name.starts_with("unoptimized") || + name.starts_with("ignore") || + name.starts_with("should_panic") || error_code.is_match(name) { - return name.to_string() + return format!("[{name}]") } let val = match caps.name("val") { diff --git a/src/ch11-00-testing.md b/src/ch11-00-testing.md index 7f11ec1494..ea85a14101 100644 --- a/src/ch11-00-testing.md +++ b/src/ch11-00-testing.md @@ -25,8 +25,9 @@ We can write tests that assert, for example, that when we pass `3` to the we make changes to our code to make sure any existing correct behavior has not changed. -Testing is a complex skill: although we can’t cover every detail about how to -write good tests in one chapter, we’ll discuss the mechanics of Rust’s testing -facilities. We’ll talk about the annotations and macros available to you when -writing your tests, the default behavior and options provided for running your -tests, and how to organize tests into unit tests and integration tests. +Testing is a complex skill: although we can’t cover in one chapter every detail +about how to write good tests, in this chapter we will discuss the mechanics of +Rust’s testing facilities. We’ll talk about the annotations and macros +available to you when writing your tests, the default behavior and options +provided for running your tests, and how to organize tests into unit tests and +integration tests. diff --git a/src/ch11-01-writing-tests.md b/src/ch11-01-writing-tests.md index 03bf244c69..5c6452a7bd 100644 --- a/src/ch11-01-writing-tests.md +++ b/src/ch11-01-writing-tests.md @@ -4,9 +4,9 @@ Tests are Rust functions that verify that the non-test code is functioning in the expected manner. The bodies of test functions typically perform these three actions: -1. Set up any needed data or state. -2. Run the code you want to test. -3. Assert the results are what you expect. +* Set up any needed data or state. +* Run the code you want to test. +* Assert that the results are what you expect. Let’s look at the features Rust provides specifically for writing tests that take these actions, which include the `test` attribute, a few macros, and the @@ -19,8 +19,8 @@ attribute. Attributes are metadata about pieces of Rust code; one example is the `derive` attribute we used with structs in Chapter 5. To change a function into a test function, add `#[test]` on the line before `fn`. When you run your tests with the `cargo test` command, Rust builds a test runner binary that runs -the annotated functions and reports on whether each -test function passes or fails. +the annotated functions and reports on whether each test function passes or +fails. Whenever we make a new library project with Cargo, a test module with a test function in it is automatically generated for us. This module gives you a @@ -43,15 +43,16 @@ $ cd adder The contents of the *src/lib.rs* file in your `adder` library should look like Listing 11-1. -+ @@ -61,9 +62,9 @@ cd ../../.. -For now, let’s focus solely on the `it_works()` function. Note the -`#[test]` annotation: this attribute indicates this is a test function, so the -test runner knows to treat this function as a test. We might also have non-test +For now, let’s focus solely on the `it_works` function. Note the `#[test]` +annotation: this attribute indicates this is a test function, so the test +runner knows to treat this function as a test. We might also have non-test functions in the `tests` module to help set up common scenarios or perform common operations, so we always need to indicate which functions are tests. @@ -84,24 +85,26 @@ The `cargo test` command runs all tests in our project, as shown in Listing Cargo compiled and ran the test. We see the line `running 1 test`. The next -line shows the name of the generated test function, called `it_works`, and that -the result of running that test is `ok`. The overall summary `test result: ok.` -means that all the tests passed, and the portion that reads `1 passed; 0 -failed` totals the number of tests that passed or failed. +line shows the name of the generated test function, called `tests::it_works`, +and that the result of running that test is `ok`. The overall summary `test +result: ok.` means that all the tests passed, and the portion that reads `1 +passed; 0 failed` totals the number of tests that passed or failed. It’s possible to mark a test as ignored so it doesn’t run in a particular instance; we’ll cover that in the [“Ignoring Some Tests Unless Specifically Requested”][ignoring] section later in this chapter. Because we -haven’t done that here, the summary shows `0 ignored`. We can also pass an -argument to the `cargo test` command to run only tests whose name matches a -string; this is called *filtering* and we’ll cover that in the [“Running a -Subset of Tests by Name”][subset] section. We also haven’t -filtered the tests being run, so the end of the summary shows `0 filtered out`. +haven’t done that here, the summary shows `0 ignored`. The `0 measured` statistic is for benchmark tests that measure performance. Benchmark tests are, as of this writing, only available in nightly Rust. See [the documentation about benchmark tests][bench] to learn more. +We can pass an argument to the `cargo test` command to run only tests whose +name matches a string; this is called *filtering* and we’ll cover that in the +[“Running a Subset of Tests by Name”][subset] section. Here we +haven’t filtered the tests being run, so the end of the summary shows `0 +filtered out`. + The next part of the test output starting at `Doc-tests adder` is for the results of any documentation tests. We don’t have any documentation tests yet, but Rust can compile any code examples that appear in our API documentation. @@ -110,7 +113,7 @@ write documentation tests in the [“Documentation Comments as Tests”][doc-comments] section of Chapter 14. For now, we’ll ignore the `Doc-tests` output. -Let’s start to customize the test to our own needs. First change the name of +Let’s start to customize the test to our own needs. First, change the name of the `it_works` function to a different name, such as `exploration`, like so: Filename: src/lib.rs @@ -136,7 +139,7 @@ is to call the `panic!` macro. Enter the new test as a function named ```rust,panics,noplayground -{{#rustdoc_include ../listings/ch11-writing-automated-tests/listing-11-03/src/lib.rs:here}} +{{#rustdoc_include ../listings/ch11-writing-automated-tests/listing-11-03/src/lib.rs}} ``` @@ -152,11 +155,16 @@ Run the tests again using `cargo test`. The output should look like Listing + + Instead of `ok`, the line `test tests::another` shows `FAILED`. Two new sections appear between the individual results and the summary: the first displays the detailed reason for each test failure. In this case, we get the details that `another` failed because it `panicked at 'Make this test fail'` on -line 10 in the *src/lib.rs* file. The next section lists just the names of all +line 17 in the *src/lib.rs* file. The next section lists just the names of all the failing tests, which is useful when there are lots of tests and lots of detailed failing test output. We can use the name of a failing test to run just that test to more easily debug it; we’ll talk more about ways to run tests in @@ -185,7 +193,7 @@ method, which are repeated here in Listing 11-5. Let’s put this code in the ```rust,noplayground -{{#rustdoc_include ../listings/ch11-writing-automated-tests/listing-11-05/src/lib.rs:here}} +{{#rustdoc_include ../listings/ch11-writing-automated-tests/listing-11-05/src/lib.rs}} ``` @@ -204,13 +212,13 @@ has a width of 5 and a height of 1. -Note that we’ve added a new line inside the `tests` module: `use super::*;`. -The `tests` module is a regular module that follows the usual visibility rules -we covered in Chapter 7 in the [“Paths for Referring to an Item in the Module +Note the `use super::*;` line inside the `tests` module. The `tests` module is +a regular module that follows the usual visibility rules we covered in Chapter +7 in the [“Paths for Referring to an Item in the Module Tree”][paths-for-referring-to-an-item-in-the-module-tree] section. Because the `tests` module is an inner module, we need to bring the code under test in the outer module into the scope of the inner module. We use -a glob here so anything we define in the outer module is available to this +a glob here, so anything we define in the outer module is available to this `tests` module. We’ve named our test `larger_can_hold_smaller`, and we’ve created the two @@ -254,16 +262,16 @@ Running the tests now produces the following: {{#include ../listings/ch11-writing-automated-tests/no-listing-03-introducing-a-bug/output.txt}} ``` -Our tests caught the bug! Because `larger.width` is 8 and `smaller.width` is -5, the comparison of the widths in `can_hold` now returns `false`: 8 is not +Our tests caught the bug! Because `larger.width` is `8` and `smaller.width` is +`5`, the comparison of the widths in `can_hold` now returns `false`: 8 is not less than 5. ### Testing Equality with the `assert_eq!` and `assert_ne!` Macros A common way to verify functionality is to test for equality between the result of the code under test and the value you expect the code to return. You could -do this using the `assert!` macro and passing it an expression using the `==` -operator. However, this is such a common test that the standard library +do this by using the `assert!` macro and passing it an expression using the +`==` operator. However, this is such a common test that the standard library provides a pair of macros—`assert_eq!` and `assert_ne!`—to perform this test more conveniently. These macros compare two arguments for equality or inequality, respectively. They’ll also print the two values if the assertion @@ -288,9 +296,10 @@ Let’s check that it passes! {{#include ../listings/ch11-writing-automated-tests/listing-11-07/output.txt}} ``` -We pass `4` as the argument to `assert_eq!`, which is equal to the result of -calling `add_two(2)`. The line for this test is `test tests::it_adds_two ... -ok`, and the `ok` text indicates that our test passed! +We create a variable named `result` that holds the result of calling +`add_two(2)`. Then we pass `result` and `4` as the arguments to `assert_eq!`. +The output line for this test is `test tests::it_adds_two ... ok`, and the `ok` +text indicates that our test passed! Let’s introduce a bug into our code to see what `assert_eq!` looks like when it fails. Change the implementation of the `add_two` function to instead add `3`: @@ -306,18 +315,18 @@ Run the tests again: ``` Our test caught the bug! The `it_adds_two` test failed, and the message tells -us that the assertion that fails was ``assertion `left == right` failed`` -and what the `left` and `right` values are. This message helps us start -debugging: the `left` argument was `4` but the `right` argument, where we had -`add_two(2)`, was `5`. You can imagine that this would be especially helpful -when we have a lot of tests going on. +us ``assertion `left == right` failed`` and what the `left` and `right` values +are. This message helps us start debugging: the `left` argument, where we had +the result of calling `add_two(2)`, was `5` but the `right` argument was `4`. +You can imagine that this would be especially helpful when we have a lot of +tests going on. Note that in some languages and test frameworks, the parameters to equality assertion functions are called `expected` and `actual`, and the order in which we specify the arguments matters. However, in Rust, they’re called `left` and `right`, and the order in which we specify the value we expect and the value the code produces doesn’t matter. We could write the assertion in this test as -`assert_eq!(4, add_two(2))`, which would result in the same failure message +`assert_eq!(4, result)`, which would produce the same failure message that displays `` assertion failed: `(left == right)` ``. The `assert_ne!` macro will pass if the two values we give it are not equal and @@ -471,7 +480,7 @@ This test will pass because the value we put in the `should_panic` attribute’s `expected` parameter is a substring of the message that the `Guess::new` function panics with. We could have specified the entire panic message that we expect, which in this case would be `Guess value must be less than or equal to -100, got 200.` What you choose to specify depends on how much of the panic +100, got 200`. What you choose to specify depends on how much of the panic message is unique or dynamic and how precise you want your test to be. In this case, a substring of the panic message is enough to ensure that the code in the test function executes the `else if value > 100` case. @@ -503,7 +512,7 @@ Our tests so far all panic when they fail. We can also write tests that use E>` and return an `Err` instead of panicking: ```rust,noplayground -{{#rustdoc_include ../listings/ch11-writing-automated-tests/no-listing-10-result-in-tests/src/lib.rs}} +{{#rustdoc_include ../listings/ch11-writing-automated-tests/no-listing-10-result-in-tests/src/lib.rs:here}} ``` The `it_works` function now has the `Result<(), String>` return type. In the diff --git a/src/ch11-02-running-tests.md b/src/ch11-02-running-tests.md index 6445826eff..406b06e681 100644 --- a/src/ch11-02-running-tests.md +++ b/src/ch11-02-running-tests.md @@ -1,14 +1,14 @@ ## Controlling How Tests Are Run -Just as `cargo run` compiles your code and then runs the resulting binary, -`cargo test` compiles your code in test mode and runs the resulting test +Just as `cargo run` compiles your code and then runs the resultant binary, +`cargo test` compiles your code in test mode and runs the resultant test binary. The default behavior of the binary produced by `cargo test` is to run all the tests in parallel and capture output generated during test runs, preventing the output from being displayed and making it easier to read the output related to the test results. You can, however, specify command line options to change this default behavior. -Some command line options go to `cargo test`, and some go to the resulting test +Some command line options go to `cargo test`, and some go to the resultant test binary. To separate these two types of arguments, you list the arguments that go to `cargo test` followed by the separator `--` and then the ones that go to the test binary. Running `cargo test --help` displays the options you can use @@ -72,13 +72,13 @@ When we run these tests with `cargo test`, we’ll see the following output: {{#include ../listings/ch11-writing-automated-tests/listing-11-10/output.txt}} ``` -Note that nowhere in this output do we see `I got the value 4`, which is what -is printed when the test that passes runs. That output has been captured. The +Note that nowhere in this output do we see `I got the value 4`, which is +printed when the test that passes runs. That output has been captured. The output from the test that failed, `I got the value 8`, appears in the section of the test summary output, which also shows the cause of the test failure. -If we want to see printed values for passing tests as well, we can tell Rust -to also show the output of successful tests with `--show-output`. +If we want to see printed values for passing tests as well, we can tell Rust to +also show the output of successful tests with `--show-output`: ```console $ cargo test -- --show-output @@ -157,11 +157,11 @@ here: Filename: src/lib.rs ```rust,noplayground -{{#rustdoc_include ../listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/src/lib.rs}} +{{#rustdoc_include ../listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/src/lib.rs:here}} ``` -After `#[test]` we add the `#[ignore]` line to the test we want to exclude. Now -when we run our tests, `it_works` runs, but `expensive_test` doesn’t: +After `#[test]`, we add the `#[ignore]` line to the test we want to exclude. +Now when we run our tests, `it_works` runs, but `expensive_test` doesn’t: ```console {{#include ../listings/ch11-writing-automated-tests/no-listing-11-ignore-a-test/output.txt}} @@ -175,7 +175,7 @@ the ignored tests, we can use `cargo test -- --ignored`: ``` By controlling which tests run, you can make sure your `cargo test` results -will be fast. When you’re at a point where it makes sense to check the results -of the `ignored` tests and you have time to wait for the results, you can run -`cargo test -- --ignored` instead. If you want to run all tests whether they’re -ignored or not, you can run `cargo test -- --include-ignored`. +will be returned quickly. When you’re at a point where it makes sense to check +the results of the `ignored` tests and you have time to wait for the results, +you can run `cargo test -- --ignored` instead. If you want to run all tests +whether they’re ignored or not, you can run `cargo test -- --include-ignored`. diff --git a/src/ch11-03-test-organization.md b/src/ch11-03-test-organization.md index a8c19b6a6c..323f01a74a 100644 --- a/src/ch11-03-test-organization.md +++ b/src/ch11-03-test-organization.md @@ -23,14 +23,14 @@ in each file to contain the test functions and to annotate the module with #### The Tests Module and `#[cfg(test)]` -The `#[cfg(test)]` annotation on the tests module tells Rust to compile and run -the test code only when you run `cargo test`, not when you run `cargo build`. -This saves compile time when you only want to build the library and saves space -in the resulting compiled artifact because the tests are not included. You’ll -see that because integration tests go in a different directory, they don’t need -the `#[cfg(test)]` annotation. However, because unit tests go in the same files -as the code, you’ll use `#[cfg(test)]` to specify that they shouldn’t be -included in the compiled result. +The `#[cfg(test)]` annotation on the `tests` module tells Rust to compile and +run the test code only when you run `cargo test`, not when you run `cargo +build`. This saves compile time when you only want to build the library and +saves space in the resultant compiled artifact because the tests are not +included. You’ll see that because integration tests go in a different +directory, they don’t need the `#[cfg(test)]` annotation. However, because unit +tests go in the same files as the code, you’ll use `#[cfg(test)]` to specify +that they shouldn’t be included in the compiled result. Recall that when we generated the new `adder` project in the first section of this chapter, Cargo generated this code for us: @@ -41,14 +41,13 @@ this chapter, Cargo generated this code for us: {{#rustdoc_include ../listings/ch11-writing-automated-tests/listing-11-01/src/lib.rs}} ``` -This code is the automatically generated test module. The attribute `cfg` -stands for *configuration* and tells Rust that the following item should only -be included given a certain configuration option. In this case, the -configuration option is `test`, which is provided by Rust for compiling and -running tests. By using the `cfg` attribute, Cargo compiles our test code only -if we actively run the tests with `cargo test`. This includes any helper -functions that might be within this module, in addition to the functions -annotated with `#[test]`. +On the automatically generated `tests` module, the attribute `cfg` stands for +*configuration* and tells Rust that the following item should only be included +given a certain configuration option. In this case, the configuration option is +`test`, which is provided by Rust for compiling and running tests. By using the +`cfg` attribute, Cargo compiles our test code only if we actively run the tests +with `cargo test`. This includes any helper functions that might be within this +module, in addition to the functions annotated with `#[test]`. #### Testing Private Functions @@ -106,7 +105,7 @@ adder └── integration_test.rs ``` -Enter the code in Listing 11-13 into the *tests/integration_test.rs* file: +Enter the code in Listing 11-13 into the *tests/integration_test.rs* file. @@ -116,13 +115,12 @@ Enter the code in Listing 11-13 into the *tests/integration_test.rs* file: -Each file in the `tests` directory is a separate crate, so we need to bring our +Each file in the *tests* directory is a separate crate, so we need to bring our library into each test crate’s scope. For that reason we add `use -adder::add_two` at the top of the code, which we didn’t need in the unit -tests. +adder::add_two;` at the top of the code, which we didn’t need in the unit tests. We don’t need to annotate any code in *tests/integration_test.rs* with -`#[cfg(test)]`. Cargo treats the `tests` directory specially and compiles files +`#[cfg(test)]`. Cargo treats the *tests* directory specially and compiles files in this directory only when we run `cargo test`. Run `cargo test` now: ```console @@ -193,11 +191,9 @@ did we call the `setup` function from anywhere: Having `common` appear in the test results with `running 0 tests` displayed for it is not what we wanted. We just wanted to share some code with the other -integration test files. - -To avoid having `common` appear in the test output, instead of creating -*tests/common.rs*, we’ll create *tests/common/mod.rs*. The project directory -now looks like this: +integration test files. To avoid having `common` appear in the test output, +instead of creating *tests/common.rs*, we’ll create *tests/common/mod.rs*. The +project directory now looks like this: ```text ├── Cargo.lock @@ -230,7 +226,7 @@ function from the `it_adds_two` test in *tests/integration_test.rs*: ``` Note that the `mod common;` declaration is the same as the module declaration -we demonstrated in Listing 7-21. Then in the test function, we can call the +we demonstrated in Listing 7-21. Then, in the test function, we can call the `common::setup()` function. #### Integration Tests for Binary Crates @@ -244,10 +240,9 @@ crates can use; binary crates are meant to be run on their own. This is one of the reasons Rust projects that provide a binary have a straightforward *src/main.rs* file that calls logic that lives in the *src/lib.rs* file. Using that structure, integration tests *can* test the -library crate with `use` to make the important functionality available. -If the important functionality works, the small amount of code in the -*src/main.rs* file will work as well, and that small amount of code doesn’t -need to be tested. +library crate with `use` to make the important functionality available. If the +important functionality works, the small amount of code in the *src/main.rs* +file will work as well, and that small amount of code doesn’t need to be tested. ## Summary