Merge pull request #330 from sarknohun/patch-6

Update chapter_21_mocking_2.asciidoc

chapter_21_mocking_2.asciidoc

@@ -1,5 +1,5 @@
 [[chapter_21_mocking_2]]
-== Mocks and Mocking 2: Using Mocks for Test Isolation
+== Using Mocks for Test Isolation
 
 .Warning, Recently Updated
 *******************************************************************************
@@ -14,12 +14,12 @@ [email protected]
 
 In this chapter we'll finish up our login system.
 While doing so, we'll explore an alternative use of mocks:
-to isolate parts of the system from each other,
-enabling more targeted testing, fight combinatorial explosion,
-and reduce duplication between tests.
+to isolate parts of the system from each other. This
+enables more targeted testing, fights combinatorial explosion,
+and reduces duplication between tests.
 
 
-NOTE: In doing so, we start to drift towards what's called "London-school TDD",
+NOTE: In this chapter, we start to drift towards what's called "London-school TDD",
     which is a variant on the "Classical" or "Detroit" style of TDD
     that I mostly show in the book.
     We won't get into the details here,
@@ -89,7 +89,7 @@ TIP: This is a good time to check out the
 ==== Straightforward Non-Mocky Test for our View
 
 Here's the most obvious test we might want to write:
-we think in terms of the _behaviour_ we want:
+thinking in terms of the _behaviour_ we want:
 
 1. If someone has a valid Token, they should get logged in
 2. If someone tries to use an invalid Token (or none), it should not log them in.
@@ -223,7 +223,7 @@ and we're considering writing equivalent tests at the views layer.
 
 === Combinatorial Explosion
 
-Let's recap the tests we might want to write at each layer in our application:
+Let's recap the tests we might want to write at each layer in our application in table 21-1:
 ((("combinatorial explosion")))
 
 .What We Want to Test in Each Layer
@@ -387,7 +387,7 @@ def login(request):
 <3> We have the "unhappy" path where the user gets an error message instead.
 
 But currently our tests are letting us "get away" with
-the cheating/wrong implementation.
+the wrong implementation.
 
 Here are three possible options for getting ourselves to the right state:
 
@@ -418,11 +418,11 @@ like playing with `.return_value`.
 ((("duplication, eliminating", id="dupel19")))
 So far we've used mocks to test external dependencies,
 like Django's mail-sending function.
-The main reason to use a mock was to isolate ourselves from external side effects,
+The main reason to use a mock we've discussed thus far is to isolate ourselves from external side effects,
 in this case, to avoid sending out actual emails during our tests.
 
 In this section we'll look at a different possible use case for mocks,
-which are around testing parts of our _own_ code in isolation from each other,
+which is testing parts of our _own_ code in isolation from each other,
 as a way of reducing duplication and avoiding combinatorial explosion in our tests.
 
 
@@ -446,7 +446,7 @@ and mocks are one way to enable that.
 
 === Starting Again, Test-Driving our Implementation With Mocks
 
-Let's see how things would look if we had made this decision in the first place.
+Let's see how things would look if we had decided to test-drive our implementation with mocks in the first place.
 We'll start by reverting all the authentication stuff,
 both from our test and from our view.
 
@@ -1206,7 +1206,7 @@ OK
 
 ((("mocks", "functional test for")))
 ((("functional tests (FTs)", "for mocks", secondary-sortas="mocks")))
-I think we're just about ready to try our functional test!
+We're just about ready to try our functional test!
 
 Let's just make sure our base template shows a different nav bar for logged-in
 and non–logged-in users (which our FT relies on):