start getting rid of the 'integrated test' terminology

chapter_03_unit_test_first_view.asciidoc

@@ -971,7 +971,8 @@ The Django Test Client does also have disadvantages;
 later in the book (in <<appendix_purist_unit_tests>>)
 we'll discuss the difference
 between fully isolated unit tests
-and the "integrated" tests that the test client pushes us towards.
+and the types of test that the test client pushes us towards
+(people often say these are technically "integration tests").
 But for now, it's very much the pragmatic choice.
 ((("", startref="testclient04")))
 ((("", startref="DJFtestclient04")))

chapter_05_post_and_database.asciidoc

@@ -887,24 +887,22 @@ NOTE: I've written this unit test in a very verbose style,
 // SEBASTIAN: This reminds me of (https://github.com/gregmalcolm/python_koans)[Python Koans].
 //    Perhaps one could link it here as an example of learning with tests
 
-.Unit Tests Versus Integrated/Integration Tests, and the Database
+.Unit Tests Versus Integration Tests, and the Database
 *******************************************************************************
-((("unit tests", "vs. integrated tests", secondary-sortas="integrated tests")))
-((("integrated tests", "vs. unit tests", secondary-sortas="unit tests")))
+((("unit tests", "vs. integration tests", secondary-sortas="integration tests")))
+((("integration tests", "vs. unit tests", secondary-sortas="unit tests")))
 Some people will tell you that a "real" unit test should never touch the database,
-and that the test I've just written should be more properly called an
-"integrated" test, or "integration" test,
-because it doesn't only test our code,
+and that the test I've just written should be more properly called an "integration" test,
+because it doesn't _only_ test our code,
 but also relies on an external system--that is, a database.
 
 It's OK to ignore this distinction for now--we have two types of test,
-the high-level functional tests which test the application from the user's
-point of view, and these lower-level tests which test it from the programmer's
-point of view.
+the high-level functional tests which test the application from the user's point of view,
+and these lower-level tests which test it from the programmer's point of view.
 
 We'll come back to this topic
-and talk about the differences between unit tests, integrated tests, integration tests, and more in <<appendix_purist_unit_tests>>,
-towards the end of the book.
+and talk about the differences between unit tests, integration tests, and more
+in <<chapter_27_hot_lava>>, at the end of the book.
 *******************************************************************************
 
 Let's try running the unit test. Here comes another unit-test/code cycle:

chapter_14_database_layer_validation.asciidoc

@@ -17,7 +17,7 @@ Once we get through these three short chapters,
 I've saved a bit of fun with JavaScript (!) for the end of <<part2>>.
 Then it's on to <<part3>>,
 where I promise we'll get right back into some of the real nitty-gritty discussions
-in TDD methodology--unit tests versus integrated tests, mocking, and more.
+in TDD methodology--unit tests versus integration tests, mocking, and more.
 Stay tuned!
 
 

chapter_27_hot_lava.asciidoc

@@ -7,11 +7,11 @@ The database is Hot Lava!
 ______________________________________________________________
 
 
-((("integrated tests", "vs. unit tests", secondary-sortas="unit tests")))
-((("unit tests", "vs. integrated tests", secondary-sortas="integrated tests")))
+((("integration tests", "vs. unit tests", secondary-sortas="unit tests")))
+((("unit tests", "vs. integration tests", secondary-sortas="integration tests")))
 Unless you've been through <<appendix_purist_unit_tests>>,
 almost all of the "unit" tests in the book
-should perhaps have been called 'integrated' tests,
+should perhaps have been called _integration_ tests,
 because they either rely on the database or use the Django Test Client,
 which does too much magic with the middleware layers that sit between requests,
 responses, and view functions.