Re: [boost] Boost Test Tools Library Proposal

From: Beman Dawes (beman_at_[hidden])
Date: 2000-12-08 13:44:16

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