Chapter 1. crpcut philosophy

Because, even though there are many C++ unit test systems out there, none covered all the desired properties, although many covered some:

Because it protects the tests from each other. One failed test cannot easily corrupt the environment for any other test.

It also makes it possible to handle inadvertent crashes and even infinite loops as any other failure.

Not really. The overhead is very low, typically much less than a millisecond, so you would need a very long suite of very short tests for this to matter. Experience shows that build-time for a test program is typically much longer than the run-time, and the test programs are usually build-once/run-once.

In addition, crpcut allows you to run tests in parallel, which on a multi-core CPU can reduce run time considerably, especially if individual tests are time consuming.

It is a bad idea just because it is the natural C++ error reporting mechanism. A unit under test could accidentally prevent an error report from being captured. Consider the following class, that needs testing:

    class catchall
    {
    public:
      catchall(int n);
    };

    inline catchall::catchall(int n)
    {
      try {
        stubbed_function(n);
      }
      catch (...)
      {
         std::cerr << "something bad happened, but I saved the day" << std::endl;
      }
    }

Assume a macro THROW_ON_ERROR that behaves like an assert, except that it throws. It is used by the stub to verify that the caller does the right thing.

    int expected_value = 0;
    void stubbed_function(int n)
    {
      THROW_ON_ERROR(n != expected_value);
    }

Now we write a test for this program:

     TEST(construct_catchall_with_wrong_value)
     {
       expected_value = 3;
       catchall object(2);
     }

See what's wrong?

What is better depends on the situation. Some times it is no use to continue a test after a failed condition, because the state is not one that makes sense for the rest of the test. At other times, more checked conditions can give more insight into what went wrong.

This is why crpcut offers both ASSERT macros, that terminate the test process on failure, and VERIFY macros, that allow execution to continue even when the test is marked as failed.

Which is better to use is a judgement call from case to case.

It was not an easy decision, but the reason is simple. As ugly as the implementation is, the ease of use is phenomenal. You focus on writing test logic instead of writing boiler plate code to match the test engine's implementation.

Correction, they are standardized in ISO/IEC 14882:2011.

While few, if any, compilers supports the standard in full, most compilers today supports the functionality required for crpcut, and has done so for years. The advantage gained in ease of writing test cases far outweighs the disadvantage of not working with a select few old compilers.

	Note
	It is only the test code itself that must be compiled with support for the new standard functionality. The units under test do not.