Re: [boost] [Release 1.34] Supported Compilers - another view

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2006-02-01 14:08:19

On Wed, 01 Feb 2006 09:34:14 -0500
David Abrahams <dave_at_[hidden]> wrote:

> >> It's all good and interesting but would you prefer minimal testing 
> >> component? You stuck with a single BOOST_CHECK tool and couldn't
> >> figure out  why particular assertion fails. You could use debugger
> >but > using  BOOST_CHEKK_EQUAL would give you much more change to
> >figure it > you quicker  without one.
> >
> >
> > Without a doubt, Boost.Test singlehandedly eliminated one of my
> > biggest objections to test-first coding.  
> 
> Which objection and how does Boost.Test eliminate it?

Early attempts were stopped because creating and running the tests were
just too difficult and time consuming.  Later attempts resulted in a mix
of C/C++ with test scripts written in python, perl, ruby, etc.  This was
better, but there was still way too much going on, and it took a long
time to use the system, write tests, run scripts, and such.  The test
framework was not clean and easy to use.

I experienced a fair amount of effort in startup of using Boost.Test
(about a week or so), but once I started using it and got a handle on
the parts that seemed most use to me, it became very easy to write tests
and integrate them into the build process.

The framework allows for easy test-writing.  I use the library, but part
of my Boost install is to build all libs anyway, so it's not a big deal.

I can run "make tests" at the top of my build tree, and it will build
all the code, and run the tests.  When I need more tests, I can simply
create a new .cpp file with the basic few lines of template, and start
inserting my tests.  For more complex tests, I use the unit test
classes, but for almost everything else, the basic stuff is plenty.

Most of the TEST macros are very easy to use, though the documentation
can be a bit confusing at times.  I was quite surprised at the depth of
this library after using it for a while.

Thus, after integrating Boost.Test into my process, I find writing and
maintaining good tests is not so difficult (I still have to write proxy
objects for complex integration testing... someone needs to come up with
a good solution for that).

I really like the flexible error reporting.  I do not set any
environment variables in my shell.  Instead, my makefiles handle all of
that (by default, they do nothing, I think, which means the defaults are
reasonable --- for me at least), and I can override it when I call make.

When I am doing things the right way, I can quickly write up some tests,
then develop until they all pass.  Sometimes, as I write the
implementation, I think of a strange scenario that I have to code
around.  When that happens I SHOULD go write the test.  Before using
Boost.Test I NEVER did that because it was too cumbersome, and often,
the test needed to change as well causign more problems.

The Boost.Test tools make writing them much simpler than my previous
tools.  I really don't have an excuse to do otherwise (at least for unit
tests).  I am still lacking good integration testing tools.  Lots of my
code is related to distributed systems, so I have to write lots of proxy
objects.  Blech.