Loading ...
Sorry, an error occurred while loading the content.

[extremeprogramming] Re: CppUnit learning curve [Was: Civilian Pairing]

Expand Messages
  • jweirich@one.net
    ... Phlip There s the rub. Because DBC advocates halting the program Phlip at an error, a CppUnit-style program won t be able to count Phlip the errors. I m
    Message 1 of 17 , Jan 28, 2000
    • 0 Attachment
      >>>>> "Phlip" == Phlip <phlip@...> writes:

      Phlip> There's the rub. Because DBC advocates halting the program
      Phlip> at an error, a CppUnit-style program won't be able to count
      Phlip> the errors. I'm unsure if counting the errors is exactly a
      Phlip> requirement, since any error is enough to force a bug hunt.

      Actually, this is a miss-characterization of DbC. When a contract is
      violated in DbC, the resulting behavior is *undefined*. This means
      the failing program may throw an exception, halt the program, core
      dump, or reformat your hard disk.

      If you are just "running the program" with DbC checks enabled, halting
      the program is not a bad choice since the program state may be
      corrupted at that point. A CppUnit style test frame tends to isolate
      the state between tests, so dumping the test and starting the next
      test makes a lot of sense.

      I believe this was brought in up in discussion of running without a
      test framework (or perhaps with a light weight test framework). If
      there is a provision for isolating the state of the tests, then define
      your "assert" macros to throw an exception and have a light weight
      framework move on to the next class. Without test to test isolation,
      you may be better off just aborting.

      -- Jim Weirich jweirich@... http://w3.one.net/~jweirich
      -- "A distributed system is one in which I cannot get something done
      -- because a machine I've never heard of is down." --Leslie Lamport
    Your message has been successfully submitted and would be delivered to recipients shortly.