diff --git a/src/ch11-01-writing-tests.md b/src/ch11-01-writing-tests.md
index 0dc9bfc..fd8e3f3 100644
--- a/src/ch11-01-writing-tests.md
+++ b/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() {
}
```
+
+Listing 11-1: A test expecting a `panic!`
+
+
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() {
}
```
+
+
+
+Listing 11-2: A test expecting a `panic!` with a particular message
+
+
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
diff --git a/src/ch11-02-running-tests.md b/src/ch11-02-running-tests.md
index be12082..abb5b6d 100644
--- a/src/ch11-02-running-tests.md
+++ b/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() {
}
```
+
+Listing 11-3: Three tests with a variety of names
+
+
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 {
}
```
+
+Listing 11-4: Tests in two modules named `adding` and `subtracting`
+
+
Running `cargo test` will run all of the tests, and the module names will
appear in the test names in the output:
diff --git a/src/ch11-03-test-organization.md b/src/ch11-03-test-organization.md
index 3bc1578..25bb8dd 100644
--- a/src/ch11-03-test-organization.md
+++ b/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 {
}
```
+
+Listing 11-5: Testing the function `add_two` in a child `tests` module
+
+
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 {
}
```
+
+Listing 11-6: Testing a private function
+
+
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() {
}
```
+
+Listing 11-7: An integration test of a function in the `adder` crate
+
+
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