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

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-01 15:47:46

Jody Hagins <jody-boost-011304_at_[hidden]> writes:

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

Easier than BOOST_ASSERT?

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

That's all build system stuff and has nothing to do with the library.
I do

  bjam test

and get the same result.

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

  #include <boost/assert.hpp>

  int main()
  {
      ...
      BOOST_ASSERT( whatever );
      ...
      BOOST_ASSERT( whatever );
  }

> For more complex tests, I use the unit test classes, 

What classes, please?

> but for almost everything else, the basic stuff is plenty.

I think that might be my point.

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

Yes.  What do you get from those macros that's very useful beyond what
BOOST_ASSERT supplies?  I really want to know.  Some people I'll be
consulting with next week want to know about testing procedures for
C++, and if there's a reason to recommend Boost.Test, I'd like to do
that.

> 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).

Proxy objects?  Oh, I think someone described this to me: a proxy
object is basically a stub that you use as a stand-in for the real
thing?  There was a guy I met at SD Boston who was all fired up with
ideas for such a library -- I think he had written one.  I encouraged
him to post about it on the Boost list so the domain experts and
people who really cared could respond, and he said he would,
but... well, as in about 75% of such scenarios, he never did.

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

I don't see why that was hard before Boost.Test.  I have absolutely no
problem writing new tests using BOOST_ASSERT.  Having the Boost.Build
primitives to specify tests is a big help, but as I've said, that's
independent of any language-level testing facility.

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

Blech.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com