more improvements in chap 4 flowcharts + discussion

Author: hjwp

chapter_philosophy_and_refactoring.asciidoc

@@ -786,8 +786,7 @@ It's time for a little recap, and perhaps even some flowcharts.
 Forgive me, years misspent as a management consultant have ruined me.
 On the plus side, it will feature recursion.
 
-What is the overall TDD process? 
-
+What is the overall TDD process?
 Well, one very common way to present it is using the three words
 _Red, Green, Refactor_. See <<red-green-refactor>>..
 
@@ -798,37 +797,40 @@ image::images/red-green-refactor-excalidraw.png["Red, Green and Refactor as thre
 What if we want to drill down in a bit more detail?  Here's what
 we've been doing, including what I call the _unit test/code cycle_:
 
-We write a test. We run the test and see it fail.
-We write some minimal code to get it a little further.
-We rerun the test and repeat until it passes.
-Then, we look for opportunities to refactor our code,
-using our tests to make sure we don't break anything. See <<simple-tdd-diagram>>.
+* We write a test.
+* We run the test and see it fail.
+* We write some minimal code to get it a little further.
+* We rerun the test and repeat until it passes (the unit test / code cycle)
+* Then, we look for opportunities to refactor our code,
+  using our tests to make sure we don't break anything.
+
+See <<simple-tdd-diagram>>.
+
 
 [[simple-tdd-diagram]]
-.Overall TDD process
+.Overall TDD process including the unit test / code cycle
 image::images/tdd-process-unit-tests-only-excalidraw.png["A flowchart with boxes for tests, coding and refactoring, with yes/no labels showing when we move forwards or backwards"]
 
 But how does this apply when we have functional tests _and_ unit tests?
-Well, you can think of the functional test as being a high-level view of the cycle,
+Well, you can think of the functional test as driving a higher-level version of the same cycle,
 where "writing the code" to get the functional tests to pass
-actually involves using another, smaller TDD cycle which uses unit tests.
+actually involves using another, smaller TDD cycle driven by unit tests.
 See <<double-loop-tdd-diagram>>.
 
-We write a functional test and see it fail.
-Then, the process of "writing code" to get it to pass is a mini-TDD cycle of its own:
-we write one or more unit tests, and go into the unit-test/code cycle until the unit tests pass.
-Then, we go back to our FT to check that it gets a little further,
+* WWe write a functional test and see it fail.
+* Then, the process of "writing code" to get it to pass is a mini-TDD cycle of its own:
+    * we write one or more unit tests, and go into the unit-test/code cycle until the unit tests pass.
+* Then, we go back to our FT to check that it gets a little further,
 and we can write a bit more of our application--using more unit tests, and so on.
 
-TODO - a little more nuance here
+TODO - next paragraph needs work.  clarification.
 
 What about refactoring, in the context of functional tests?
 Well, that means we use the functional test to check that we've preserved the behaviour of
 our application, but we can change or add and remove unit tests, and use
 a unit test cycle to actually change the implementation.
 
-The functional tests are the ultimate judge of whether your application works
-or not.  The unit tests are a tool to help you along the way.
+The functional tests are the final sanity-check that your application works. The unit tests are there to help you figure out all the lower level bits you need along the way.
 
 This way of looking at things is sometimes called "Double-Loop TDD". One of my
 eminent tech reviewers, Emily Bache, wrote http://bit.ly/1iXzoLR[a blog post]