Sync md and docx

Author: carols10cents

listings/ch11-writing-automated-tests/listing-11-07/src/lib.rs

@@ -1,4 +1,4 @@
-pub fn add_two(a: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     a + 2
 }
 

listings/ch11-writing-automated-tests/listing-11-11/src/lib.rs

@@ -1,4 +1,4 @@
-pub fn add_two(a: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     a + 2
 }
 

listings/ch11-writing-automated-tests/listing-11-12/src/lib.rs

@@ -1,8 +1,8 @@
-pub fn add_two(a: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     internal_adder(a, 2)
 }
 
-fn internal_adder(left: usize, right: usize) -> usize {
+fn internal_adder(left: u64, right: u64) -> u64 {
     left + right
 }
 

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: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     a + 3
 }
 // ANCHOR_END: here

listings/ch11-writing-automated-tests/output-only-04-running-ignored/output.txt

@@ -4,7 +4,7 @@ $ cargo test -- --ignored
      Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)
 
 running 1 test
-test expensive_test ... ok
+test tests::expensive_test ... ok
 
 test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s
 

listings/ch11-writing-automated-tests/output-only-04-running-ignored/src/lib.rs

@@ -1,12 +1,22 @@
-// ANCHOR: here
-#[test]
-fn it_works() {
-    assert_eq!(2 + 2, 4);
+pub fn add(left: u64, right: u64) -> u64 {
+    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

nostarch/chapter11.md

@@ -139,7 +139,7 @@ The `cargo test` command runs all tests in our project, as shown in Listing
 $ cargo test
    Compiling adder v0.1.0 (file:///projects/adder)
     Finished `test` profile [unoptimized + debuginfo] target(s) in 0.57s
-     Running unittests src/lib.rs (file:///projects/adder/target/debug/deps/adder-7acb243c25ffd9dc)
+     Running unittests src/lib.rs (target/debug/deps/adder-01ad14159ff659ab)
 
 running 1 test
 test tests::it_works ... ok
@@ -151,6 +151,7 @@ test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; fini
 running 0 tests
 
 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
@@ -164,7 +165,7 @@ 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`. 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
+string; this is called *filtering* and we’ll cover it 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`.
 
@@ -274,6 +275,7 @@ test tests::exploration ... ok
 failures:
 
 ---- tests::another stdout ----
+
 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
@@ -297,12 +299,12 @@ check the line number of the panic matches the line number in the following para
 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 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
-the “Controlling How Tests Are Run” section.
+details that `tests::another` failed because it panicked with the message `Make this test fail` on 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 the “Controlling How Tests Are
+Run” section.
 
 The summary line displays at the end: overall, our test result is `FAILED`. We
 had one test pass and one test fail.
@@ -489,6 +491,7 @@ test tests::smaller_cannot_hold_larger ... ok
 failures:
 
 ---- tests::larger_can_hold_smaller stdout ----
+
 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
@@ -525,7 +528,7 @@ parameter, then we test this function using the `assert_eq!` macro.
 src/lib.rs
 
 ```
-pub fn add_two(a: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     a + 2
 }
 
@@ -565,15 +568,14 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; fini
 ```
 
 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!
+`add_two(2)`. Then we pass `result` and `4` as the arguments to the
+`assert_eq!` macro. 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: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     a + 3
 }
 ```
@@ -592,6 +594,7 @@ test tests::it_adds_two ... FAILED
 failures:
 
 ---- tests::it_adds_two stdout ----
+
 thread 'tests::it_adds_two' panicked at src/lib.rs:12:9:
 assertion `left == right` failed
   left: 5
@@ -607,20 +610,20 @@ test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out;
 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 `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.
+Our test caught the bug! The `tests::it_adds_two` test failed, and the message
+tells us that the assertion that failed was `left == right` 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
+`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, result)`, which would result in the same failure message that
-that displays `` assertion failed: `(left == right)` ``.
+displays `` assertion `left == right` failed``.
 
 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
@@ -706,6 +709,7 @@ test tests::greeting_contains_name ... FAILED
 failures:
 
 ---- tests::greeting_contains_name stdout ----
+
 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
@@ -750,6 +754,7 @@ test tests::greeting_contains_name ... FAILED
 failures:
 
 ---- tests::greeting_contains_name stdout ----
+
 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
@@ -962,6 +967,7 @@ test tests::greater_than_100 - should panic ... FAILED
 failures:
 
 ---- tests::greater_than_100 stdout ----
+
 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
@@ -1120,6 +1126,7 @@ failures:
 
 ---- tests::this_test_will_fail stdout ----
 I got the value 8
+
 thread 'tests::this_test_will_fail' panicked at src/lib.rs:19:9:
 assertion `left == right` failed
   left: 10
@@ -1173,6 +1180,7 @@ failures:
 
 ---- tests::this_test_will_fail stdout ----
 I got the value 8
+
 thread 'tests::this_test_will_fail' panicked at src/lib.rs:19:9:
 assertion `left == right` failed
   left: 10
@@ -1201,7 +1209,7 @@ our `add_two` function, as shown in Listing 11-11, and choose which ones to run.
 src/lib.rs
 
 ```
-pub fn add_two(a: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     a + 2
 }
 
@@ -1366,7 +1374,7 @@ $ cargo test -- --ignored
      Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)
 
 running 1 test
-test expensive_test ... ok
+test tests::expensive_test ... ok
 
 test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s
 
@@ -1458,11 +1466,11 @@ Consider the code in Listing 11-12 with the private function `internal_adder`.
 src/lib.rs
 
 ```
-pub fn add_two(a: usize) -> usize {
+pub fn add_two(a: u64) -> u64 {
     internal_adder(a, 2)
 }
 
-fn internal_adder(left: usize, right: usize) -> usize {
+fn internal_adder(left: u64, right: u64) -> u64 {
     left + right
 }
 

nostarch/docx/chapter11.docx

@@ -98,7 +98,7 @@ instance; we’ll cover that in the [“Ignoring Some Tests Unless Specifically
 Requested”][ignoring]<!-- ignore --> 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
+string; this is called _filtering_ and we’ll cover it in the [“Running a
 Subset of Tests by Name”][subset]<!-- ignore --> section. Here we haven’t
 filtered the tests being run, so the end of the summary shows `0 filtered out`.
 
@@ -164,13 +164,13 @@ check the line number of the panic matches the line number in the following para
 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 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
-the [“Controlling How Tests Are Run”][controlling-how-tests-are-run]<!-- ignore
---> section.
+details that `tests::another` failed because it panicked with the message `Make
+this test fail` on 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 the [“Controlling How Tests Are
+Run”][controlling-how-tests-are-run]<!-- ignore --> section.
 
 The summary line displays at the end: overall, our test result is `FAILED`. We
 had one test pass and one test fail.
@@ -298,9 +298,9 @@ Let’s check that it passes!
 ```
 
 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!
+`add_two(2)`. Then we pass `result` and `4` as the arguments to the
+`assert_eq!` macro. 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`:
@@ -315,20 +315,20 @@ Run the tests again:
 {{#include ../listings/ch11-writing-automated-tests/no-listing-04-bug-in-add-two/output.txt}}
 ```
 
-Our test caught the bug! The `it_adds_two` test failed, and the message tells us
-that the assertion that failed was ``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.
+Our test caught the bug! The `tests::it_adds_two` test failed, and the message
+tells us that the assertion that failed was `left == right` 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), result)`, which would result in the same failure message
-that displays `` assertion failed: `(left == right)` ``.
+`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, result)`, which would result in the same failure message that
+displays `` assertion `left == right` failed``.
 
 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