anchor.diff:  
   If you require another custom reporter you need to resort to the
   standard, programatic, way of invoking your tests. For now...
  +
  +
  +Ignoring Tests
  +~~~~~~~~~~~~~~
  +
  +Sometimes you find that you need to temporarily remove a test, perhaps
  +to do a refactoring with a failing test. Ignoring it will allow you to do the
  +refactoring while still in the green.
  +
  +An old practice is then to comment it out. That is a slightly cumbersome
  +and hazardous habit as there is no indication of a missing test if you
  +forget to uncomment it when you are done.
  +
  +*Cgreen* offers a much better solution. You can just add an 'x' infront
  +of the `Ensure` for the test.
  +
  +[source, C]
  +----------------------------
  +...
  +xEnsure(Reader, ...) {
  +  ...
  +}
  +...
  +----------------------------
  +
  +With this method, it is a one character change to temporarily ignore,
  +and un-ignore, a test. It is also easily found using text searches through
  +a complete source tree. And in a near future *Cgreen* will also tally the
  +ignored tests, so it is visible when you run your tests.
   
   
   Mocking functions with Cgreen
  
positive.code: 
  All done.
  
  === Mocks Are...
  
  Using mocks is a very handy way to isolate a unit and catch and
  control calls to external units. Depending on your style of coding two
  
negative.code: style ensures that the corresponding `BeforeEach()` and `AfterEach()`
  are run before and after each test.
  
  NOTE: The `cgreen-runner` __will__ discover your tests in a shared
  library even if you don't use the BDD-ish style. But it will not be
  able to find and run the `setup()` and/or `teardown()` attached to your
  suite(s).
  
  In case you have non-BDD style tests __without__ any `setup()` and/or
  `teardown()` you can still use the runner. The default suite/context
  where the tests live in this case is called `default`. But why don't
  you convert your tests to BDD notation? This removes the risk of
  frustrating trouble-shooting when you added `setup()`
  and `teardown()` and can't understand why they are not run...
  
  So, the runner incourages you to use the BDD notation. But since we
  recommend that you do anyway, that's no extra problem if you are
  starting out from scratch. But see <<changing_style>> for some easy
  tips on how to get you there if you already have non-BDD
  tests.
  
  You can choose between the TextReporter, which we have been seeing so
  