Hudson, C++ and UnitTest++

Question

Has anyone used Hudson as a Continuous-Integration server for a C++ project using UnitTest++ as a testing library?

How exactly did you set it up?

I know there have been several questions on Continuous Integration before, but I hope this one has a narrower scope.

EDIT: I'll clarify a bit on what I'm looking for. I already have the build set to fail when the Unit-Tests fail. I'm looking for something like Hudson's JUnit support. UnitTest++ can create XML reports (See here). So, perhaps if someone knows how to translate these reports to be JUnit compatible, Hudson will know how to eat it up?

Answer 1

We are actively doing this at my workplace.

Currently, we use a free-style software project to:

• Check our Subversion repository for updates every 15 minutes
• Call a windows batch file to clean and build a solution file
  • Project files build and run unit tests as a post-build event
  • Unit test failures are returned by the test main(), thus treated as build errors

I have also tested a configuration that uses the XmlTestReporter included with UnitTest++ to generate output files. The xUnit plugin natively supports this output, along with any other output you can convert, although I had to change the XSL file that came with it in version 0.1.3 to get durations recorded in the test history.

There are a lot of things we would like to improve about our integration; the build logs are long and hard to parse with no coloring or highlighting, etc., but so far it has still been beneficial to us.

Answer 2

I checked the xUnit plugin, as Patrick Johnmeyer suggested in the accepted answer. For completeness sakes, here is the driver code:

#include <fstream>
#include "UnitTest++.h"
#include "XmlTestReporter.h"

int main( int argc, char *argc[] ) {
    std::ofstream f("file.xml");
    UnitTest::XmlTestReporter reporter(f);
    return UnitTest::RunAllTests(reporter, UnitTest::Test::GetTestList(), NULL, 0);
}

In Hudson configuration, check "Publish testing tools result report" and point it to "file.xml"

Answer 3

Hudson now has a CppUnit plugin that may do the trick.

Answer 4

Long before I started to use Hudson, I worked on a C++ project where we used cpp-unit-lite and CruiseControl

We altered Cpp-unit-lite to generate JUnit like XML report files and CruiseControl picked up the XML report files.

You can do the same for UnitTest++ and Hudson will pickup the report files.

However, that seems like a lot of work. Have a look at the plot plugin for Hudson. You can have a script extract the number of failing/passing tests from the UnitTest++ output and use the plot plugin to draw a simple graph of passing/failing tests per build.

Not as nice as the in-built unit test report but something you can get working quickly.

Answer 5

I use hudson with CppUnit and xml output. The xml are translated by xslt to a JUnit output like. CppUnit site provides an xslt that convert CppUnit output to JUnit output. I have hacked it a bit in order to get mre details like :

• namespaces as packages
• execution time

you may transform your xml output to get the following:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite>
   <testcase name="my test name"
             classname="Package1.Package2.TestClass"
             time="0.25">
      <error type="error"/>
   </testcase>
   ....
</testsuite>

In case of success : just remove the sub tag

Regards

Answer 6

We've been using a similar approach at my office, except using cxxtest instead of UnitTest++, and now we're in the process to migrating to google's vastly superior (imho) gtest framework.

With cxxtest, we did something similar to what Patrick J. suggested, which was to basically add a build step which would run the test suite program via ant and cause the build to fail if any tests fail. The disadvantage of this approach is when the build fails due to a test result, then you have to go hunting through the console output to figure out what went wrong. Also you loose the nifty charts which hudson can generate if your test framework can output junit-compatible XML.

One of the motivating factors to switch to gtest is that it does generate junit XML, so in theory, hudson can parse the test results and publish them in a more sensible manner. Anyways, it doesn't look like UnitTest++ generates anything like this (please correct me if I'm wrong), so it might be a moot point, but at least integrating it into your build process will make sure that the tests get run during builds.