Who Is Using Cpp Unit

Please tell if you use CppUnit and how you refactored it (if you did).

We try to integrate some of the CppUnit stuff into the OpenOffice.org automated test environment. We've done a lot of changes there. E.g. We use another STL, we don't need the CppUnit GUI stuff, make cppunit compatible to our Linux and Solaris environment, integrate a signal handler, because lot of bugs within Unix occur not as exceptions but as signals. If any one is interested in more, do not hesitate to contact me via email, lla<at>openoffice.org. -- Lars Langhans

I am using CppUnit for my individual project. I am using a separate configuration in VC6 called Test that started as a copy of my Debug configuration. This is so I can give out Debug builds that don't actually run tests.

Each of the DLLs in my project runs its own suite of tests when DllMain gets hit with a DLL_PROCESS_ATTACH (everything in one process, so multiple test runs aren't really an issue). If the tests fail DllMain returns FALSE preventing the DLL from loading and in turn shutting down the app.

Error results from tests are spit out to the debug console in VC file(line) : message format so I can double click on them to jump straight to source. Makes it very easy to just compile and run. If somethings broken I know right away, otherwise there's no interference with the application and everything proceeds normally.

-- MatthewDouglass?

We are using CppUnit with Visual CeePlusPlus 6.0. We did some refactoring for outputting name of test suites and number of tests and suites done. We also changed a little bit some of the variable names to be easier to understand. -- JeanMarcHeneman

I used it on a MFC project to turn the Question Mark Button on the tool bar, in Debug-mode, from an About button to a Test button. This raises the TestRunner.

Then I added a Debug-mode-only flag to the command lines, "-test", to automatically raise this test and automatically bang its Run button. This involved a slight refeaturization - TestRunner had to click its own Run button at display time.

Then I wrote a batch file that called the project with its -test flag on the command line.

Then I called that batch file from a Makefile as the last action under a target called 'test'.

Then I called that Makefile from a clicker in the Quick Launch tray of my Task Bar.

Almost forgot one more feature. I made the name of each failed test appear in via DebugOutputString? in my output tab in file(99) format. This lets me use "next compile error" navigation to locate the assert failures.

Warning: The hoary hirsute set will tell you UTs run in both Debug and Release mode. Screw it - the 80/20 rule applies.

-- PhlIp

EvanCofsky. I'm using its text interface pretty much straight, except I removed all \r characters from the files.

I'm using it with GnuCpp (on a Linux-Box) also with the text interface. I had several problems with it and had to change some things (also the \r's). But at last it works. -- JuergenLindemeyer

I wrote a variation (or an enhanced version?) of CppUnit which we used with Kai, MSVC, and now GCC. I refactored it heavily, in fact it is written from scratch. You can see some of my thought process in CppUtxOverview. We needed more heavy duty testing so I added some more UserStories, such as:

I've since moved to another project - this one in Java - but if I remember correctly, those were the biggest changes. Oh yeah, I also changed the way tests and test suites are named. In CppUtx, I used names that were qualified with a sort of TestSuite path similar to how a file name is qualified by its path. Here are some examples of how a CppUtx test driver could be invoked: 

 test -quiet -csv test.csv      // Run all tests quietly -- create a csv file of results
 test root.i18n.CharEncoderTest? // Run all CharEncoderTest? cases in the i18n package
 test root.i18n.CharEncoderTest?.TestEncode? // Run only the TestEncode? case
 test TestExceptions?            // Run case in every suite it occurs
 test root.core.string // Run all tests in the core.string package (i.e. suite)
 test core.*           // Run all tests in all the core packages
This made it relatively painless for a programmer to run only their tests or for QA to run some pattern of tests when tracking down a bug. I used this same naming convention to optionally allow command lines for individual test cases. This was done using a simple file with the following layout: 

 ;
 ; test.def -- command lines for suites or individual cases
 ;
 root.core.thr.ThreadTest? -threads 256
 root.util.ParserTest? -in shakespeare.dat
 root.logger.LogTest?.TestClient? -server ten.ada.net
These are made up names and command lines, but you get the idea. Because of the hierarchical property of test names, you could send a command line argument to all tests with an entry like so: 

 ; test.def
 root -verbose  ; send this flag to all test methods
Not that you'd really need an option like this, but the feature came for free when I changed the naming model of CppUtx. In a test method, you would access the command line just as you would in a main routine: 

 class MyClassTest
 {
    public:


       void TestSomeMethod( const TestContext& ctx )
       {
          TestContext::argv_iterator 
             at = ctx.ArgvBegin(),
             end = ctx.ArgvEnd();


          std::string sTestName = *at++; // "<path>.TestSome?Method"


          while ( at != end )
          {
              // process command line
          }
       }
 };
Since this is C++, I made argv[0] the qualified name of the test. I'd say all in all, that while command lines were very rarely used, it was very easy to add and became very important to those tests which used it. I laid out my thought process in CppUtxOverview. -- RobertDiFalco

I got CppUnit a rather long time ago, and I haven't recently compared it with what is currently available... The first refactoring I did was to fix the header inclusions. I also created a SimpleTestCase? class that was a subclass of TestCase, overriding setup() and teardown() to do nothing, because most of my TestCase subclasses don't need to override setup() and teardown(). In VC++, there were compile problems with referencing test functions in an STL vector, so my work-around is to have one "inner" subclass of SimpleTestCase? per test. When I have time, I'll get the latest CppUnit and compare it with my version, and either upgrade mine, or submit my changes to the world at large.

Oh yes, my copies of Junit and CppUnit also write out more progress and timing information, so I know which tests are taking a long time.

I don't suppose anyone has done a PowerPlant version of CppUnit?

-- KeithRay

As of January 2003 there are Mac CodeWarrior examples on my website at http://www.oofile.com.au/downloads.html which currently use just the TextRunner? but include full instructions on how to build from a simple console project using either CodeWarrior Pro6 on MacOS 8.6 or Pro 8.3 on OS/X.

This distribution includes an example which is a set of WideString? conversion functions to match the Win32 shell API and some tests for the standard string functions I wrote as part of a current project.

I would like to do a PowerPlant version when I have a bit more time but there are a few paid jobs and other tasks in front of that one.

-- AndyDent

I am using CppUnit at Proxyconn (http://www.proxyconn.com). I have used if on previous projects for other companies. I am currently using it to test parts of our server which can be built for both Linux and Windows. I am hooked on CppUnit, and I don't trust any code that has no test case. Using CppUnit is the only way to guarentee that half million lines of code is perfect and stays perfect. I like perfection; I like CppUnit. -- ShawnB

I am using it for company project. Now the only part of the code that doesn't have UnitTest is where the program have to be called from other library (It's like event loop here that i don't know yet how to simulate such callback). Even though the overhead of making Unittest in static type language like C++ is much of a burden in itself, I'm happy to spend hours to have unit test fail now than spending days when my program crash later. CppUnit help me catch those little silly mistake as well as some big bug. -- PisinBootvong

I have been using CppUnit for a commercial project (1.2 million significant LinesOfCode ) since April 2004. Breaking dependencies so that you can test infect a large body legacy code can be slow going, so I have been focusing on UnitTesting new features and the framework and libraries.

Besides helping me catch problems earlier, I have found that the discipline of minimizing dependencies in order to make code more testable has helped make my modules easily reusable. -- GeoffBurns

CategoryCpp CategoryTesting

EditText of this page (last edited February 6, 2007) or FindPage with title or text search