Boost logo

Boost :

From: Thomas Matelich (sosedada_at_[hidden])
Date: 2000-12-08 16:08:08

Beman Dawes wrote:

> At 09:16 PM 12/7/2000 +0100, Ullrich Koethe wrote:
> >I followed the discussion about a unit test library and had a look at
> >"test_tools". I realized that this library's intend is very close to a
> >unit test library I've been using for a long time in my own projects,
> >with very good results. Thus, I'm submitting my library "unittest.h" for
> >consideration. The file is attached to the mail.
> >
> >"unittest.h" was designed following the ideas of Kent Becks "JUnit"
> >(see ""). It has the following features:
> >
> > ...
> Several people have suggested unit tests in the past, I think mostly based
> on JUnit. Perhaps the reason we haven't made more progress on such ideas
> in the past is that there are three needs (at least as seen by me):
> 1) A main() replacement for console apps which turns as many problems as
> possible into a uniform return code. Note that while this is useful for
> testing, it is also very useful for production programs, and so shouldn't
> carry a lot of baggage related only to testing. It is helpful if it is
> very easy to retrofit to legacy programs, too.
> [Asside: I think I forgot the message the names send when when I boostified
> the names. May need to rethink names so as not to scare off users with
> need (1)]
> 2) Support for very simple tests like the test tools example:
> #include <boost/test_tools_main.hpp>
> #include <boost/test_tools.hpp>
> int add( int i, int j ) { return i+j; }
> int test_main( int argc, char * argv[] ) // note the name!
> {
> // four ways to detect and report the same error:
> BOOST_TEST_VERIFY( add(2,2) == 4 ); // #1 continues on error
> BOOST_TEST_ASSERT( add(2,2) == 4 ); // #2 throws on error
> if ( add(2,2) != 4 ) throw "Oops..."; // #3 throws on error
> return add(2,2) == 4 ? 0 : 1; // #4 returns error directly
> }
> In other words, no need to derive from some base class like
> TestSuite. Very, very, simple so it is as easy as possible to use for
> small, simple tests. Can be understood well enough to use correctly in a
> few moments.
> 3) Support for unit tests in the sense of JUnit.
> In the past it always seemed to me that proposals didn't even address (1)
> and (2), which I perceive as a primary need at boost (and a lot of other
> places). Like the other proposals, unittest.h seems focused on (3) pretty
> exclusively, although I only skimmed the code, so could be wrong.
> >Any interest in this tool?
> Definately! But in the context of needs (1), (2), and (3).
> --Beman

I think unittest.h could easily satisy all these requirements.
1) Many choices here. My first thought is to set things up to have a single
TestSuite which all individual TestSuites add themselves to.

2) A function like createTestCase, working with a system like above, would
fairly quickly solve this requirement.

3) Got it.

I think for class testing xUnit functionality is absolutely required. The
ability to inherit tests can be a godsend.

Thomas O Matelich
Senior Software Designer
Zetec, Inc.

Boost list run by bdawes at, gregod at, cpdaniel at, john at