Adding some listing numbers

src/ch11-01-writing-tests.md

@@ -229,7 +229,7 @@ is useful when we want to test that calling a particular function will cause an
 error. For example, let's test something that we know will panic from Chapter
 8: attempting to create a slice using range syntax with byte indices that
 aren't on character boundaries. Add the `#[should_panic]` attribute before the
-function like the `#[test]` attribute:
+function like the `#[test]` attribute, as shown in Listing 11-1:
 
 Filename: src/lib.rs
 
@@ -242,6 +242,10 @@ fn slice_not_on_char_boundaries() {
 }
 ```
 
+<caption>
+Listing 11-1: A test expecting a `panic!`
+</caption>
+
 This test will succeed, since the code panics and we said that it should. If
 this code happened to run and did not cause a `panic!`, this test would fail.
 
@@ -249,7 +253,8 @@ this code happened to run and did not cause a `panic!`, this test would fail.
 didn't fail for a different reason than the one you were expecting. To help
 with this, an optional `expected` parameter can be added to the `should_panic`
 attribute. The test harness will make sure that the failure message contains
-the provided text. A safer version of the example above would be:
+the provided text. A safer version of Listing 11-1 would be the following, in
+Listing 11-2:
 
 Filename: src/lib.rs
 
@@ -262,6 +267,12 @@ fn slice_not_on_char_boundaries() {
 }
 ```
 
+<!-- I will add ghosting in libreoffice /Carol -->
+
+<caption>
+Listing 11-2: A test expecting a `panic!` with a particular message
+</caption>
+
 Try on your own to see what happens when a `should_panic` test panics but
 doesn't match the expected message: cause a `panic!` that happens for a
 different reason in this test, or change the expected panic message to

src/ch11-02-running-tests.md

@@ -48,7 +48,7 @@ working on code in a particular area, you might want to only run the tests
 having to do with that code. `cargo test` takes an argument that allows you to
 only run certain tests, specified by name.
 
-Let's create three tests with the following names:
+Let's create three tests with the following names as shown in Listing 11-3:
 
 Filename: src/lib.rs
 
@@ -69,6 +69,10 @@ fn one_hundred() {
 }
 ```
 
+<caption>
+Listing 11-3: Three tests with a variety of names
+</caption>
+
 Running with different arguments will run different subsets of the tests. No
 arguments, as we've already seen, runs all the tests:
 
@@ -115,7 +119,7 @@ test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured
 Module names become part of the test name, so module names can be used in a
 similar way to run just the tests for a particular module. For example, if our
 code was organized into a module named `adding` and a module named
-`subtracting` with tests in each:
+`subtracting` with tests in each, as in Listing 11-4:
 
 ```rust
 mod adding {
@@ -143,6 +147,10 @@ mod subtracting {
 }
 ```
 
+<caption>
+Listing 11-4: Tests in two modules named `adding` and `subtracting`
+</caption>
+
 Running `cargo test` will run all of the tests, and the module names will
 appear in the test names in the output:
 

src/ch11-03-test-organization.md

@@ -61,7 +61,7 @@ this is a common use of globs.
 Up until now in this chapter, we've been writing tests in our `adder` project
 that don't actually call any code we've written. Let's change that now! In
 *src/lib.rs*, place this `add_two` function and `tests` module that has a test
-function to exercise the code:
+function to exercise the code, as shown in Listing 11-5:
 
 Filename: src/lib.rs
 
@@ -81,6 +81,10 @@ mod tests {
 }
 ```
 
+<caption>
+Listing 11-5: Testing the function `add_two` in a child `tests` module
+</caption>
+
 Notice in addition to the test function, we also added `use add_two;` within
 the `tests` module. This brings the code we want to test into the scope of the
 inner `tests` module, just like we'd need to do for any inner module. If we run
@@ -115,8 +119,8 @@ everything into the `test` module scope at once.
 There's controversy within the testing community about whether you should write
 unit tests for private functions or not. Regardless of which testing ideology
 you adhere to, Rust does allow you to test private functions due to the way
-that the privacy rules work. Consider this code with the private function
-`internal_adder`:
+that the privacy rules work. Consider the code in Listing 11-6 with the private
+function `internal_adder`:
 
 Filename: src/lib.rs
 
@@ -140,6 +144,10 @@ mod tests {
 }
 ```
 
+<caption>
+Listing 11-6: Testing a private function
+</caption>
+
 Because tests are just Rust code and the `tests` module is just another module,
 we can import and call `internal_adder` in a test just fine. If you don't think
 private functions should be tested, there's nothing in Rust that will compel
@@ -159,9 +167,9 @@ Cargo has support for integration tests in the *tests* directory. If you make
 one and put Rust files inside, Cargo will compile each of the files as an
 individual crate. Let's give it a try!
 
-First, make a *tests* directory at the top level of your project directory, next
-to *src*. Then, make a new file, *tests/integration_test.rs*, and put this
-inside:
+First, make a *tests* directory at the top level of your project directory,
+next to *src*. Then, make a new file, *tests/integration_test.rs*, and put the
+code in Listing 11-7 inside:
 
 Filename: tests/integration_test.rs
 
@@ -174,6 +182,10 @@ fn it_adds_two() {
 }
 ```
 
+<caption>
+Listing 11-7: An integration test of a function in the `adder` crate
+</caption>
+
 We now have `extern crate adder` at the top, which we didn't need in the unit
 tests. Each test in the `tests` directory is an entirely separate crate, so we
 need to import our library into each of them. This is also why `tests` is a