anchor.diff:  $ make install
   -----------------------------------------
   
  -The initial `make` command will configure the build process and
  -create a separate `build` directory before going there and building
  -using *CMake*. This is called an 'out of source build'. It compiles
  -*Cgreen* from outside the sources directory. This helps the overall
  -file organization and enables multi-target builds from the same
  -sources by leaving the complete source tree untouched.
  -
  -TIP: Experienced users may tweak the build configuration by going to
  -the build subdirectory and use `ccmake ..` to modify the build
  -configuration in that subtree.
  -
  -TIP: The Makefile is just there for convenience, it just creates the
  -build directory and invokes *CMake* there, so that you don't have
  -to. This means that experienced *CMake* users can just do as they
  -normally do with a *CMake*-based project instead of invoking `make`.
  -
  -The build process will create a library (on unix called
  -`libcgreen.so`) which can be used in conjunction with the `cgreen.h`
  -header file to compile and link your test code. The created library is
  -installed in the system, by default in the `/usr/local/lib/`.
  +The initial `make` command will configure the build process and create a separate `build` directory before going there and building using *CMake*.
  +This is called an 'out of source build'.
  +It compiles *Cgreen* from outside the sources directory.
  +This helps the overall file organization and enables multi-target builds from the same sources by leaving the complete source tree untouched.
  +
  +TIP: Experienced users may tweak the build configuration by going to the build subdirectory and use `ccmake ..` to modify the build configuration in that subtree.
  +
  +TIP: The Makefile is just there for convenience, it just creates the build directory and invokes *CMake* there, so that you don't have to.
  +This means that experienced *CMake* users can just do as they normally do with a *CMake*-based project instead of invoking `make`.
  +
  +The build process will create a library (on unix called `libcgreen.so`) which can be used in conjunction with the `cgreen.h` header file to compile and link your test code.
  +The created library is installed in the system, by default in the `/usr/local/lib/`.
   
   
   ==== Your First Test
   
  -We will start demonstrating the use of *Cgreen* by writing some tests for *Cgreen* itself
  -to confirm that everything is working as it should. Let's start with a
  -simple test module with no tests, called `first_test.c`...
  +We will start demonstrating the use of *Cgreen* by writing some tests for *Cgreen* itself to confirm that everything is working as it should.
  +Let's start with a simple test module with no tests, called `first_test.c`...
   
   [source,c]
   ---------------------------------------
   include::tutorial_src/first_tests0.c[]
   ---------------------------------------
   
  -This is very unexciting. It just creates an empty test suite and runs
  -it.  It's usually easier to proceed in small steps, and this is the
  -smallest one I could think of. The only complication is the `cgreen.h`
  -header file and the mysterious looking "declarations" at the beginning
  -of the file.
  +This is very unexciting.
  +It just creates an empty test suite and runs it.
  +It's usually easier to proceed in small steps, and this is the smallest one I could think of.
  +The only complication is the `cgreen.h` header file and the mysterious looking "declarations" at the beginning of the file.
   
   The BDD flavoured *Cgreen* notation calls for a System Under Test
  -(SUT), or a 'context'. The declarations give a context to the tests
  -and it also makes it more natural to talk about which module or class,
  -the system under test, is actually responsible for the functionality
  -we are expressing. In one way we are 'describing', or spec'ing, the
  -functionality of the SUT. That's what the `Describe();` does. And for
  -technical reasons (actually requirements of the C language), you must
  -declare the `BeforeEach()` and `AfterEach()` functions even if they
  -are empty. (You will get strange errors if you don't!)
  -
  -NOTE: We are using the name "Cgreen" as the SUT in these first
  -examples, as *Cgreen* itself is the object or class we want to
  -test or describe.
  -
  -I am assuming you have the *Cgreen* folder in the include search
  -path to ensure compilation works, otherwise you'll need to add that in
  -the compilation command.
  +(SUT), or a 'context'.
  +The declarations give a context to the tests and it also makes it more natural to talk about which module or class, the system under test, is actually responsible for the functionality we are describing.
  +In one way we are 'describing', or spec'ing, the functionality of the SUT.
  +That's what the `Describe();` does.
  +And for technical reasons (actually requirements of the C language), you must declare the `BeforeEach()` and `AfterEach()` functions even if they are empty.
  +(You will get strange errors if you don't!)
  +
  +NOTE: We are using the name "Cgreen" as the SUT in these first examples, as *Cgreen* itself is the object or class we want to test or describe.
  +
  +I am assuming you have the *Cgreen* folder in the include search path to ensure compilation works, otherwise you'll need to add that in the compilation command.
   
   Then, building this test is, of course, trivial...
   
  
positive.code: 
  == Mocking functions with Cgreen
  
  When testing you want certainty above all else.  Random events destroy
  confidence in your test suite and force needless extra runs "to be
  sure".  A good test places the system under test into a tightly
  controlled environment.  A test chamber if you like.  This makes the
  tests fast, repeatable and reliable.
  
  To create a test chamber for testing code, we have to control any
  outgoing calls from the code under test.  We won't believe our test
  failure if our code is making calls to the internet for example.  The
  internet can fail all by itself.  Not only do we not have total
  control, but it also means we have to get dependent components working
  before we can test the higher level code.  This makes it difficult to
  code top down.
  
  The solution to this dilemma is to write stub code for the components
  whilst the higher level code is written.  This pollutes the code base
  with temporary code, and the test isolation disappears when the system
  is eventually fleshed out.
  
  The ideal is to have minimal stubs written for each individual test.
  *Cgreen* encourages this approach by making such tests easier to write.
  
negative.code: |=======================================================================
  
  You can specify constraints and behaviours for each expectation
  (except for `never_expect()` naturally).
  A constraint places restrictions on the parameters (and will tell you if the expected restriction was not met), and a behaviour specifies what the mock should do if the parameter constraints are met.
  
  A parameter constraint is defined using the `when(parameter, constraint)` macro.
  It takes two parameters:
  
  |=================================================
  |*Parameter* |*Description*
  