C ++ CXX测试框架

Question

How effective is the CXX test framework, given that you are writing unit test cases around the code that you have written. Any bug in the code might as well get translated into a bug in the unit test code as well? Isn't it something like two negatives make a positive?

Also, the time and effort spent on CXX is at least equal to if not more than the coding effort.

Need your thoughts on this since I'm not in favor of this framework being used in my project and am looking for strong points to oppose it.

On the other hand, if you think it's beneficial, please do enlighten me :).

Answer 1

Google offers a fantastic C++ testing framework that I have used... I never used any other C++ testing framework, and had limited experience with Junit, and I was able to pick this up very quickly, as the documentation is good. It's important to use a good testing framework, because testing is too important to give up on because of frustration with the framework. Here is a link:

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

Hope this helps!

Answer 2

CXX is not very active, and writing unit test generally involves a lot of efforts. But when the first refactoring comes in, you're very grateful of the spent effort.

I've used Boost.Test & CPPUNIT. I would prefer a little bit Boost.Test, but yes, you have to write your own projects, files etc.

If you know a tool to generate your skeleton from your code, I'm all ears. :)

I would suggest that you give a try to Boost.Test and CPPUNIT. If you think there are better it will give you good rounds to oppose CXXUNIT as you will propose alternatives.

Answer 3

I am using cxxtest. Regressive testing is an expensive task that we only use to validate our software libraries - which provide a platform independent layer for our apps. This is to ensure that all changes will not affect the stability of the code since so many apps and projects and dependent on them.

We couple cxxtest with coverage analysis to ensure that test coverage is sufficient and also with CruiseControl to automate it.

But we do not do this for apps. Too much effort.

Building a test app is just as difficult as writing the whole library itself. I agree that you will need to work out whether it is worth your while.

I think Joel has something to say about this too: http://www.joelonsoftware.com/items/2009/01/31.html

Answer 4

I prefer header-only test frameworks, here are two of them: TUT and Catch . I used TUT before in several projects, and found Catch not long ago.

1) TUT -- C++ Template Unit Test Framework

TUT is a small and portable unit test framework for C++.

• TUT is very portable, no matter what compiler or OS you use.
• TUT consists of header files only. No libraries required, deployment has never been easier.
• Custom reporter interface allows to integrate TUT with virtually any IDE or tool in the world.
• Support for multi-process testing (testing deadlocks and timeouts is under way).
• TUT is free and distributed under a BSD-like license.
• Tests are organised into named test groups.
• Regression (all tests in the application), one-group or one-test execution.
• Pure C++, no macros!

2) Catch -- A modern, C++-native, header-only, framework for unit-tests, TDD and BDD

What's the Catch?

Catch stands for C++ Automated Test Cases in Headers and is a multi-paradigm automated test framework for C++ and Objective-C (and, maybe, C). It is implemented entirely in a set of header files, but is packaged up as a single header for extra convenience.