🔒 Locked

CppUnit best practises

Started by squirrel_of_death Aug 9, 2005 at 10:59 PM 4 replies 1.5k views

Original Post

Aug 9, 2005 at 10:59 PM

Hi there. I've spent today getting CppUnit installed and working with my VC++6.0, even getting my shiny MFC green bar working ( none of this TextUi stuff! I've been spoiled by JUnit already ). So I wondering how you guys generally integrate CppUnit into your workspace / project. Right now, what I have working is a separate project for the CppUnit, and I'm going to set up test cases for the project I'm working on. My project runs the test cases as a post-build step of each compilation. Is this normal development, separating the testcases from the project itself? I kind of had the idea that the testCases would be more integrated into each project. Since I'm starting out here, thought I'd ask for any CppUnit tips / best practises before habits set in. [Edited by - squirrel_of_death on May 2, 2006 8:14:38 PM]

chollida1

Aug 9, 2005 at 11:32 PM

We don't use teh UI for unit tests. Our projects are broken into several libraries and an exe that links in the libraries.

Each library has a corresponding unit test exe taht links in the library and unit test its methods.

The unit tests are part of our solution so that when you build the library you also build the unit test project.

As a post build process, set up through visual studio. We then run the unit test. The PC version will output in the visual studio output window and the build stops if a unit tests breaks.

We also share our libraries on the Mac and Linux and use the same library and unit test code for each. Cppunit will work on those OS's as well. For Mac check out Darwinports for an easy install.

Cheers
Chris

vaugula

Aug 10, 2005 at 12:16 AM

The way I use CppUnit is to add a build target to the project for doing a unit test build and use #define directives to include or exclude files based on if they are involved in unit testing or not. That way the tests live with the rest of the source.

squirrel_of_death

Author

squirrel_of_death

Aug 10, 2005 at 11:33 AM

thanks guys, any more comments out there?

[Edited by - squirrel_of_death on May 2, 2006 8:33:45 PM]

thebolt00

Aug 10, 2005 at 12:48 PM

Ok, I should start by stating that our approach is probably more complex than most people need, but it suites our project ;)

In the project we have a few (5ish) static libs, some ten-fiftheen exes and ~30 plugins (dlls). Within the Jamfile (jam is a make replacement we use) you can define a special rule UnitTest : mydir\t which adds mydir\t as a directory that contain test snippets.
It also adds a rule named unittest (there are a few overall rules such as "test" and "testlibs") which when called combines the test snippets, create some boilerplate cpp to init the test and then run it.

Each test-snippet contains one or more cppunit fixtures and are independant which makes them easier to write (here is one example of one link )

If you browse around our CVS you'll find the autogen code too.. but it is a bit complicated ;) (iirc it is in mk\jam\unittest.jam)

-M

squirrel_of_death

Author

squirrel_of_death

Aug 10, 2005 at 1:44 PM

ok, another question. I'm having link problems right now, as the CppUnit project is in one place, and the project being tested is elsewhere. I've pointed all the directories to the right place, so I can include my headers fine, but as soon as I try testing something that is implented in a .cpp file, I get a link error.

Must I convert my project to a library in order to test it?

[Edited by - squirrel_of_death on May 2, 2006 8:44:52 PM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.