anchor.diff:  typical way to choose the named of the tests is what we see here,
   reading the declaration of the test makes sense since it is almost
   plain english, "Ensure strlen returns five for 'hello'". No problem
  -understanding what we aim to test. And it can be viewed as an example
  +understanding what we aim to test, or in TDD lingo, test drive. And it can be viewed as an example
   from a description of what strlen should be able to do. In a way,
   extracting all the `Ensure`:s from your test might give you all the
   documentation you'll need.
  
positive.code: ~~~~~~~~~~~~~~~~~~~~~~~
  
  So far we have encouraged the modern BDD style. It has merits that we
  really want you to benefit from. But you might come across another
  style, the standard TDD style, which is more inline with previous
  thinking and might be more similar to other frameworks.
  
  The only difference, in principle, is the use of the SUT or
  
negative.code: The `assert_that()` call is the primary part of an assertion, which is
  complemented with a constraint, in this case `is_equal_to()`, as a
  parameter. This makes a very fluent interface to the asserts, that
  actually reads like English. The general format is then
  
  [source, C]
  ---------------
  assert_that(actual, <assertion>);
  ---------------
  
  NOTE: Sometimes you just want to fail the test explicitly, and there
  is a function for that too, `fail_test(const char *message)`. And
  