diff --git a/second-edition/src/ch11-01-writing-tests.md b/second-edition/src/ch11-01-writing-tests.md
index b93e979e1..4b5939258 100644
--- a/second-edition/src/ch11-01-writing-tests.md
+++ b/second-edition/src/ch11-01-writing-tests.md
@@ -1,11 +1,10 @@
 ## How to Write Tests
 
-Tests are Rust functions that verify that the non-test code in the program is
-functioning in the expected manner. The bodies of test functions typically run
-some setup code, then run the code we want to test, then assert whether the
-results are what we expect. Let’s look at the features Rust provides
-specifically for writing tests: the `test` attribute, a few macros, and the
-`should_panic` attribute.
+Tests are Rust functions that verify that the non-test code is functioning in
+the expected manner. The bodies of test functions typically perform some setup,
+run the code we want to test, then assert whether the results are what we
+expect. Let’s look at the features Rust provides specifically for writing
+tests: the `test` attribute, a few macros, and the `should_panic` attribute.
 
 ### The Anatomy of a Test Function
 
@@ -19,7 +18,7 @@ on whether each test function passes or fails.
 
 We saw in Chapter 7 that when you make a new library project with Cargo, a test
 module with a test function in it is automatically generated for us. This is to
-help us get started writing our tests, since we don’t have to go look up the
+help us get started writing our tests so we don’t have to go look up the
 exact structure and syntax of test functions every time we start a new project.
 We can add as many additional test functions and as many test modules as we
 want, though!
@@ -450,7 +449,7 @@ functions that assert two values are equal are called `expected` and `actual`
 and the order in which we specify the arguments matters. However, in Rust,
 they’re called `left` and `right` instead, and the order in which we specify
 the value we expect and the value that the code under test produces doesn’t
-matter. We could have written the assertion in this test as
+matter. We could write the assertion in this test as
 `assert_eq!(add_two(2), 4)`, which would result in a failure message that says
 `` assertion failed: `(left == right)` (left: `5`, right: `4`) ``.
 
diff --git a/second-edition/src/ch11-02-running-tests.md b/second-edition/src/ch11-02-running-tests.md
index 489f2fcab..f0bc16759 100644
--- a/second-edition/src/ch11-02-running-tests.md
+++ b/second-edition/src/ch11-02-running-tests.md
@@ -154,7 +154,7 @@ function and see what the output looks like then!
 Sometimes, running a full test suite can take a long time. If you’re working on
 code in a particular area, you might want to run only the tests pertaining to
 that code. You can choose which tests to run by passing `cargo test` the name
-or names of the test/s you want to run as an argument.
+or names of the test(s) you want to run as an argument.
 
 To demonstrate how to run a subset of tests, we’ll create three tests for our
 `add_two` function as shown in Listing 11-11 and choose which ones to run:
diff --git a/second-edition/src/ch11-03-test-organization.md b/second-edition/src/ch11-03-test-organization.md
index b25f863ff..025a13eb4 100644
--- a/second-edition/src/ch11-03-test-organization.md
+++ b/second-edition/src/ch11-03-test-organization.md
@@ -9,8 +9,8 @@ tests are entirely external to your library, and use your code in the same way
 any other external code would, using only the public interface and exercising
 multiple modules per test.
 
-Both kinds of tests are important to ensure that the pieces of your library are
-doing what you expect them to separately and together.
+Writing both kinds of tests are important to ensure that the pieces of your
+library are doing what you expect them to separately and together.
 
 ### Unit Tests