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
> > 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,
-- 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