CPPUNIT_ASSERT_EQUAL and custom data types

To write more bookmark specific settings information to the configuration file I rewrote and simplified the code that reads subcommanders project settings.  I added a few tests for the new refactored code and  used a ccpunit feature  I had discovered a while ago: assertion traits.

If you have never heard of it read on and read what an assertion trait is and how it can help in handling custom data types in cppunit tests.

I’m using a custom build string class in the subversion related code to handle utf-8 encoded strings (sc::String) in Subcommander.

This works well, but there was an issue when trying to use Strings in test code:

CPPUNIT_ASSERT_EQUAL( expected, actual );

The assertion above “crashed” when printing its error message when one of the two strings was an empty string. It crashed in stl output stream code that was called by the following code inside cppunit (from TestAssert.h):

template <class T> struct assertion_traits
{
    static bool equal( const T& x, const T& y )
    {
        return x == y;
    }

    static std::string toString( const T& x )
    {
        OStringStream ost;
        ost << x;
        return ost.str();
    }
};

Very interesting code!  CPPUNIT_ASSERT_EQUAL(a,b) calls the equal method in this template to compare its two parameters a and b and calls the toString method to print the failure message if the assertion fails.

By using a template feature that’s called template specialization we can re-implement the template for a specific data type. If the compiler finds a specialization for a specific type, in my case my custom String class, it  uses the specialization for this type instead of  instantiating the generic T template for the type.

Here is the “new” code for my String class. It is nearly the same as the generic code but handles the empty string case in toString (there is also an example in cppunit’s  TestAssert.h file):

template<> struct CPPUNIT_NS::assertion_traits<sc::String>
{
  static bool equal( const sc::String& x, const sc::String& y )
  {
    return x == y;
  }

  static std::string toString( const sc::String& x )
  {
    std::string text = '"' + (!x.isEmpty() ? std::string(x) : "<null>") + '"';
    OStringStream ost;
    ost << text;
    return ost.str();
  }
};

The interesting thing about specializing the generic assertion traits is that you can add support for any custom data type to CPPUNIT_ASSERT_EQUAL with just a few lines of code.

This is even a documented feature. Surprisingly a google search on assertion_traits delivers only about 220 hits.

Either nobody knows about this feature or it just so obvious that nobody cares to write about it :-)

Creating a testrunner..

I think i finally found the easiest way to run and organize cppunit tests. Subcommander is split up into several libs and two binaries and a testrunner binary:

subcommander  (binary)
submerge      (binary)
sublib        (static lib)
util          (static lib)
svn           (static lib)
testrunner    (binary)

So far the testrunner contained the tests and linked with all the libs. The issue with this layout is that if i wanted to write a test for code in the subcommander binary and not in a library i had to add the source files to the testrunner. This gets combersome, especially with QObject based classes which also needs their moc files.

My new layout works upside down. I moved the test classes into its own libraries, …

subcommander       (binary)
subcommander-test  (static lib)
...
sublib             (static lib)
sublib-test        (static lib)
...

.. moved the testrunner code into the subcommander binary and link the binary with the test libraries. Running subcommander  with the -test command line option will run the tests. Without it, it will run the normal production code.

The test code is a lot easier to handle this way. The only drawback is that the production code now also contains all the test code… but maybe that’s not really a drawback? Everyone can run the tests now.

So far this works really good.  :-)