views:

1470

answers:

10

I believe strongly in using unit-tests as an approach to building large multi-platform applications. We currently are planning on having our unit-tests within a separate project. This has the benefit of keeping are code base clean. I think, however, that this would separate the test code from the implementation of the unit. What do you think of this approach and are there any tools like JUnit for c++ applications?

+4  A: 

That's a reasonable approach.

I've had very good results both with UnitTest++ and Boost.Test

I've looked at CppUnit, but to me, it felt more like a translation of the JUnit stuff than something aimed at C++.

Ferruccio
A: 

Cppunit is a direct equivalent of Junit for C++ applications http://cppunit.sourceforge.net/cppunit-wiki

Personally, I created the unit tests in a different project, and created a separate build configuration which built all the unit tests and dependent source code. In some cases I wanted to test private member functionss of a class so I made the Test class a friend class to the object to be tested, but hid the friend declarations when building in "non-test" configurations through preprocessor declarations.

I ended up doing these coding gymnastics as I was integrating tests into legacy code however. If you are starting out with the purpose of unit testing a better design may be simple.

NotJarvis
+4  A: 

There's a very similar question that has just been asked.

Look at CppUnit, CppUnitLite and "Working Effectively with Legacy Code" (all by Michael Feathers

Seb Rose
A: 

are there any tools like JUnit for c++ applications?

http://code.google.com/p/googletest/

A: 

You can create a unit test project for each library in your source tree in a subdirectory of that library. You end up with a test driver application for each library, which makes it easier to run a single suite of tests. By putting them in a subdirectory, it keeps your code base clean, but also keeps the tests close to the code.

Scripts can easily be written to run all of the test suites in your source tree and collect the results.

I've been using a customized version of the original CppUnit for years with great success, but there are other alternatives now. GoogleTest looks interesting.

Aaron Hinni
+1  A: 

I think your on the right path with unit testing and its a great plan to improve reliability of your product.

Though unit testing is not going to solve all your problems when converting your application to different platforms or even different operating systems. The reason for this, is the process unit testings goes through to uncover bugs in your application. It just simply throws as many inputs imaginable into your system and waits for a result on the other end. Its like getting a monkey to constantly pound at the keyboard and observing the results(Beta testers).

To take it to the next step, with good unit testing you need to focus on your internal design of your application. The best approach i found was to use a design pattern or design process called "contract programming" or "Design by contract". The other book that is very helpful for building reliability into your core design was.

Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams.

In our development team, we looked very closely at what we consider to be a programmer error, developer error, design error and how we could use both unit testing and also building reliability into our software package through DBC and following the advice of debugging the development proccess.

Chad
A: 

CxxTest is also worth a look for lightweight, easy to use cross platform JUnit/CppUnit/xUnit-like framework for C++. We find it very straightforward to add and develop tests

Aeryn is another C++ Testing Framework worth looking at

David Sykes
+3  A: 

There are many Test Unit frameforks for C++. CppUnit is certainly not the one I would choose (at least in its stable version 1.x, as it lacks many tests, and requires a lot of redundant lines of codes). So far, my preferred framework is CxxTest, and I plan on evaluating Fructose some day.

Any way, there are a few "papers" that evaluate C++ TU frameworks :

HTH,

Luc Hermitte
+2  A: 

I use UnitTest++. The tests are in a separate project but the actual tests are intertwined with the actual code. They exist in a folder under the section under test. ie:
MyProject\src\ <- source of the actual app
MyProject\src\tests <- the source of the tests
If you have nested folders (and who doesn't) then they too will have their own \tests subdirectory.

graham.reeds
We do the same, and our build system automatically builds test EXE's from code it finds under any unittest source folder.
Greg Whitfield
A: 

Using tut http://tut-framework.sourceforge.net/ very simple, just header file only no macros. Can generate XML results