Boost logo

Boost :

From: Thomas Matelich (sosedada_at_[hidden])
Date: 2000-12-07 17:34:16


Ullrich Koethe wrote:

> Thomas Matelich wrote:
> >
> > Ullrich Koethe wrote:
> >
> > > Hi there,
> > >
> > > "unittest.h" was designed following the ideas of Kent Becks "JUnit"
> > > (see "http://www.junit.org/"). It has the following features:
> >
> > I had considered suggesting an xUnit flavor (I really like the idea of using Python to test
> > C++ somehow), but upon more thought I decided against it for two reasons:
> > 1) complexity - we have more than our share of unresolved issues regarding building
> > executables. Anything that increases that is probably a bad thing. Beman's is simple and
> > sufficient (almost? can you test that an exception was thrown on error?).
> >
>
> This is not the true for "unittest.h". It is a simple command line tool
> with just 580 lines of pure C++. It doesn't have a user interface and
> doesn't require anything beyond a C++ compiler. It's not fundamentally
> different from what Beman's tool is supposed to do eventually, only that
> it has more features and has been used already.

Sorry, my bad. I should have looked more closely at your code, I got to the example code and
assumed I knew where you were going.

> > 2) non-standard - Two things here my DynCppUnit is different than the CppUnit on
> > xprogramming.com is different than Ullrich's.
>
> This might be a problem. But my understanding is that boost is trying to
> set the "standard" in terms of C++ libarary extensions, right?

I don't think boost should or could extend into this area.

>
>
> > The basic concept is the same, but I would
> > prefer to wait (and wait) for ScTest, before jumping into a more heavy-weight testing
> > framework.
> >
>
> What's ScTest ? Why do you consider "unittest.h" heavyweight ?
>

The future test tool from the Software Carpentry competition
(http://software-carpentry.codesourcery.com/sc_test).

> > On a side note to those interested in unit tests, I've got a pretty cool little thing going
> > where you put your tests (linked with the code under test) into a dynamic library and my
> > little gui loads the library and runs its tests. Essentially test plugins.
> >
>
> It's easy to build such a thing on top of "unittest.h".

Well, not so easy to do it cross platform (<shameless plug> see sourceforge.net/projects/somelib
if you want a simple plugin architecture (use cvs version) </shameless plug>).

I've just looked over unittest.h. It provides more structure than test_tools.hpp, a nice job of
obtaining the minimal xUnit functionality. I think, considering boost's opinions of compiler
support, the setjmp/longjmp and can't catch signals version should be able to be eliminated.
Here are the tests I would want to see in this tool:
assert -- or should, accepts bool
assertEquals -- with special overloads, esp. double w/ allowed error
assertThrows -- perhaps templatized. I feel this is very important, especially for a library.

My additional tests obviously can be done manually, but a tool is supposed to be useful,
correct?

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sosedada_at_[hidden]
tmatelich_at_[hidden]

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk