anchor.diff:  This gets us into the same territory as mock objects.
   
   
  +=== Important Things To Remember About `expect()` and `mock()`
  +
  +////
  +
  +TODO: The next few chapters, up to "Ruunning Tests with Mocked
  +Functions", should really be moved to a separate section. They are
  +interfering with the flow of the example with to much detailed
  +information about things that are not relevant to the example.
  +
  +We probably need a more detailed section that describes the macros
  +more in detail, with examples. Maybe lift them out to "More on
  +Mocking".
  +
  +////
  +
  +The previous chapter might have been a bit much in terms of `expect()` and `mock()`.
  +It is not always easy to follow what happens, and when.
  +
  +In order to help you avoid mistakes, here are some important things to remember when working with *Cgreen* mocks.
  +
  +- calls to `expect()` collects constraints and any other required information when it is called
  +- this also goes for `will_return()` which will save the value of its parameter _when it is called_
  +- the actual evaluation and execution of those constraints occur when `mock()` is called in the function named in the `expect()` call(s)
  +- calls to a function specified by the `expect()` calls are evaluated in the same order as the ``expect()``s were executed, but only for that named function
  +- the lexical scope of the first parameter in a `when()` is always inside the mocked function where the `mock()` call is made
  +- the lexical scope of arguments to an `is_equal_to...()` is where that call is made
  +
  +IMPORTANT: In summary, `expect()` does early collection, including evaluation of return value expression, and `mock()` does late evaluation of the constraints collected against the given arguments to `mock()`.
  +
   === Other Use Cases For Mocks
   
   ==== Out Parameters
  
positive.code: NOTE: Before you can do this you need to implement the mock functions, of course.
  I.e. write functions that replaces the real functions and instead calls `mock()`.
  
  TIP: You can try the `cgreen-mocker` for this, as described in <<cgreen-mocker>>.
  
  
  
negative.code: So your urge to refactor starts to set in.
  And that is good, go with it, we have tests to rely on.
  
  But there are a lot of things going on behind the scenes when you use *Cgreen*, often with the help of some serious macro-magic, so special care needs to be taken when refactoring tests that have `expect()` in them.
  
  ==== Renaming
  
  The first "gotcha" is when you rename a function that you mock.
  You are likely to have `expect()`s for that function too.
  
  CAUTION: the function name in an `expect()` is "text" so it will not be catched by a refactoring tool.
  You will need to change the name there manually.
  
  ==== Local Variables
  
  For example, consider this code
  
  