Re: [boost] Boost Test Tools Library Proposal

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 "http://www.junit.org/"). 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.
sosedada_at_[hidden]
tmatelich_at_[hidden]