How to use CPPUnit effectively?

[Hooyoo]

How to use CPPUnit effectively?
When I want to use CPPUnit, I always fint it useless and waste my time.
I think that's mainly
because I don't know how to use CPPUnit effectively. So if somebody
here has some experience,
please share it to me.
And also I expect answers to these questions:
1. Should I write test codes for every member function of my class? If
not, which function should be tested?
2. What else should I consider apart from checking parameters and
return value?

Thanks.

[Michael]

How to use CPPUnit effectively?

There are several schools of thought on this. One is the "Test Driven
Development" school. See Ian's excellent post or the book by the same
name. The idea is you write tests first, and then write code that
passes those tests.

But, of course, it depends on your project. Another school of thought
is the "Legacy Code" school. (See Working Effectively with Legacy Code
by Michael Feathers.) This is more appropriate if you have a large
project that already exists without tests. The key idea there is that
you add tests before changing things, so that you don't break anything,
and add tests when you add new code, so that the new code is
automatically tested. Over time, more and more of the code is tested.

It depends on your use model. If you're writing code only for
yourself, you probably won't need as much. I tend to not write tests
for obvious things (does a + b work), but for things that have a high
chance of being buggy (does my code work to find the last element in
the array? what if the array is empty?). And particularly for things
with complex logic, where I know it's right, but I fear some other
developer will miss the subtlety of all that a given method does, and
will change it in a way that breaks part (but not all) of the behavior.

One of the best uses I've ever seen was in complex database code that
then did some complex business logic processing processing, followed by
complex display to a browser. By isolating the business logic in unit
tests, you could get it right, and if there was a bug, you didn't have
to start up the database and the web server, so tracking down problems
took seconds instead of minutes.

Another really good use is if you ever find a bug. Don't fix the bug.
Instead, write a test that replicates the bug, then fix the code so it
passes the test. That way, you've fixed the bug, and it will stay
fixed forever (i.e., some other programmer won't reintroduce it).

Sadly, the greatest use of unit tests is when you start getting
coverage over part of code, and it may take a while to get there. At
that point you can feel really confident changing code without breaking
things, and you're confident the code works correctly.

Michael

[Roland Pibinger]

On 30 Oct 2006 19:07:57 -0800, "Hooyoo" <zh*********@12 6.comwrote:

>How to use CPPUnit effectively?
When I want to use CPPUnit, I always fint it useless and waste my time.
I think that's mainly
because I don't know how to use CPPUnit effectively. So if somebody
here has some experience, please share it to me.
And also I expect answers to these questions:
1. Should I write test codes for every member function of my class? If
not, which function should be tested?
2. What else should I consider apart from checking parameters and
return value?

For beginners to C++ Unit Tests the following article may be helpful:
Chuck Allison: The Simplest Automated Unit Test Framework That Could
Possibly Work - http://www.ddj.com/dept/cpp/184401279

Good luck,
Roland Pibinger

[Roland Pibinger]

On Tue, 31 Oct 2006 04:12:06 GMT, "Phlip" <ph******@yahoo .comwrote:

>Hooyoo wrote:

>How to use CPPUnit effectively?

Use UnitTest++. It's much leaner and easier to use:

http://unittest-cpp.sourceforge.net/

CppUnit is stuffed with features you won't need, and they often get in the
way of the few you do.

I guess a good C++ unit test 'framework' is yet to be written. Most of
the available frameworks are cluttered up with macros which IMO is
rather repelling.

Best regards,
Roland Pibinger

[Gianni Mariani]

Roland Pibinger wrote:

On Tue, 31 Oct 2006 04:12:06 GMT, "Phlip" <ph******@yahoo .comwrote:

>Hooyoo wrote:

>>How to use CPPUnit effectively?

Use UnitTest++. It's much leaner and easier to use:

http://unittest-cpp.sourceforge.net/

CppUnit is stuffed with features you won't need, and they often get in the
way of the few you do.

I guess a good C++ unit test 'framework' is yet to be written. Most of
the available frameworks are cluttered up with macros which IMO is
rather repelling.

There are 4 macros in the Austria C++ unit test framework.

They are:

AT_TestArea - define a test area
AT_DefineTest - define a test
AT_RegisterTest - register a test
AT_TCAssert - "Test case assert" which throws a test case exception

I lied, there is another version of AT_DefineTest that takes a little
more tweaking.

So, what's so "repelling" ?

Oh - btw, here is one of the unit tests.. You can define any number of
unit tests in a file and you can link as many files unit test files as
you like into a single executable. It uses the Austria generic factories
so all the unit tests register themselves automatically.

That's about it. WHAT is repelling about that and what would you do
differently ?

#include "at_bw_transfor m.h"

#include "at_unit_test.h "

using namespace at;

AT_TestArea( ATBWTransform, "BW Transform" );

#include <iostream>

AT_DefineTest( Basic, ATBWTransform, "Basic BW Transform code test" )
{
void Run()
{
std::string test_str = "fun faster fast";

std::vector<cha r test_result( test_str.size() );

unsigned i = BWTEncode( test_str.begin( ), test_str.end(),
test_result.beg in() );

std::cout << "BW( \"" << test_str << "\" ) = (" << i << ") \""
<< std::string( test_result.beg in(), test_result.end () ) <<
"\"\n";

std::vector<cha r test_decode( test_str.size() );

BWTDecode( i, test_result.beg in(), test_result.end (),
test_decode.beg in() );

std::cout << "Decode( \"" << std::string( test_result.beg in(),
test_result.end () ) << "\" ) (" << i << ") $
<< std::string( test_decode.beg in(), test_decode.end () ) <<
"\"\n";

AT_TCAssert( std::string( test_decode.beg in(),
test_decode.end () ) == test_str, "BWT decode failed" );
}
};

AT_RegisterTest ( Basic, ATBWTransform );

[Roland Pibinger]

On Tue, 31 Oct 2006 21:54:48 +1100, Gianni Mariani
<gi*******@mari ani.wswrote:

>Roland Pibinger wrote:

>I guess a good C++ unit test 'framework' is yet to be written. Most of
the available frameworks are cluttered up with macros which IMO is
rather repelling.

There are 4 macros in the Austria C++ unit test framework. They are:
AT_TestArea - define a test area
AT_DefineTes t - define a test
AT_RegisterTes t - register a test
AT_TCAssert - "Test case assert" which throws a test case exception
I lied, there is another version of AT_DefineTest that takes a little
more tweaking.

So, what's so "repelling" ?

I've not been aware of your Austria framework (even though I live in
Austria. BTW, why haven't you named it Italia?). My favorite unit test
'framework' still is the Standard 'assert' (admittedly a macro in most
implementations ).

Best wishes,
Roland Pibinger

[Gianni Mariani]

Roland Pibinger wrote:
...

>So, what's so "repelling" ?

I've not been aware of your Austria framework (even though I live in
Austria. BTW, why haven't you named it Italia?). My favorite unit test
'framework' still is the Standard 'assert' (admittedly a macro in most
implementations ).

Because it started off as a country that started with "A". The next
project is Borneo. Besides I think the Austrian's are the most fun
people in Europe.

Hmm. AT_TCAssert gives you the line number and file name (and stack
trace if you want) of the failure and allows you to run the rest of the
tests. You get a full report on all the test failures not just the
first one to fail.

Anyhow, if you're happy with assert, more power to you !

[Phlip]

Roland Pibinger wrote:

I guess a good C++ unit test 'framework' is yet to be written. Most of
the available frameworks are cluttered up with macros which IMO is
rather repelling.

One Noel Llopis once wrote a book on C++ for game programmers. You should
have seen how he twitched when first I showed him my TEST_() macro (based on
the CppUnitLite TEST() macro). Game programmers are known to abuse macros in
false pursuit of efficiency, and I expect his book ranted against them.

And now his UnitTest++ has exactly the same suite of macros.

In a C language, thou shalt write an assertion with a macro. Even the
various published style guides say so. Further, you can generally write a
better assertion than many vaunted soft languages can support.

In C++, use a macro for any of these techniques:

- conditional compilation
- extracting compiler-defined constants (like __LINE__)
- stringerization
- token pasting

You need all of them for a powerful and flexible unit test rig.

People who are repelled by any language technique, without actually
understanding its uses and costs, are not on the path to wisdom.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Dave Steffen]

"Hooyoo" <zh*********@12 6.comwrites:

How to use CPPUnit effectively? When I want to use CPPUnit, I
always fint it useless and waste my time. I think that's mainly
because I don't know how to use CPPUnit effectively. So if somebody
here has some experience, please share it to me.

Our first cut at a home-grown unit test framework was very much like
JUnit / CPPUnit. The amount of extra verbage needed for even the
simplest tests was a major problem.

We moved to Boost's unit test framework about a year ago, and it's
_much_ better. None of this "unit tests are classes that inherit
from..." stuff, each unit test is a free function.

Roland P. won't like it, because it's replete with macros. :-) But
the "auto unit test" facility is very handy, and does a very, very
important thing: it makes writing unit tests extremely cheap.

I recommend that you check it out.

----------------------------------------------------------------------
Dave Steffen, Ph.D. Disobey this command!
Software Engineer IV - Douglas Hofstadter
Numerica Corporation
dg@steffen a@t numer@ica d@ot us (remove @'s to email me)

[Phlip]

Dave Steffen wrote:

We moved to Boost's unit test framework about a year ago, and it's
_much_ better. None of this "unit tests are classes that inherit
from..." stuff, each unit test is a free function.

Fixtures are a unit test Best Practice, so test rigs should enable them.
Both UnitTest++ and my TEST_() enable them without requiring them. Boost's
doesn't. But indeed do check it out; it _is_ Boost, after all!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Roland Pibinger]

On 31 Oct 2006 13:44:44 -0700, Dr. Dave Steffen wrote:

We moved to Boost's unit test framework about a year ago, and it's
_much_ better. None of this "unit tests are classes that inherit
from..." stuff, each unit test is a free function.

Roland P. won't like it, because it's replete with macros. :-) But
the "auto unit test" facility is very handy, and does a very, very
important thing: it makes writing unit tests extremely cheap.

If you are fond of boosted stuff TUT might interest you (not that I
recommend it). It uses built-in C++ macros (a.k.a. templates) instead
of preprocessor macros: http://tut-framework.sourceforge.net/

Best regards,
Roland Pibinger