Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-02-01 20:00:55


> Autolinking is nonportable, and you have to set up _some_ kind of path
> so that the libraries can be found by the linker.

Not if you are using bjam

> It has to build once for each toolset, and then again each time the
> test library changes. Yes, a small inconvenience, but an
> inconvenience nonetheless.

1. If you are doing a lot of testing it's tiny work in comparison with all
the test you are building/running
2. You could always choose to use inlined version. On powerful box
compilation time difference is almost negligable

>> And if Boost.<any other component you depend on> breaks you are not?
>
> I can usually fix those, or workaround the problem. With Boost.Test
> my workaround for any problem is to fall back on BOOST_ASSERT and
> wonder why I bother.

So essencially you don't use any tools you dont have direct control over.
And again see next statement

>> Actually Boost.Test is quite stable for a while now.
>
> It's not a predisposition; it's borne of experience. Every time I try
> to use the library, thinking it's probably the right thing to do, and
> wanting to like it, I find myself wondering what I've gained for my
> investment. Until you can hear that and respond accordingly --
> instead of dismissing it as the result of predisposition -- Boost.Test
> is going to continue to be a losing proposition for me.

I am not quite sure what you want me to hear. How should I enhance the
library for you to find it worth your investements.

>> BOOST_CHECK don't; if expression throw an exception you need to start a
>> debugger to figure out what is going on - using Boost.Test in majority of
>> the cases it's clear from test output.
>
> It's hard to imagine what test output could allow me to diagnose the
> cause of an exception. Normally, the cause is contained in the
> context (e.g. backtrace, etc.) and that information is lost during
> exception unwinding.

It depends how you organize you program. My exception classes frquently
report failure location along with erro cause. So instead of stepping throw
whole stack inside the debugger I jump directly into source code.

>> And I think you are seriously mistaken.
>
> That may be so. Maybe you should point me at some Boost regression
> tests that benefit heavily from Boost.Test so I can get a feeling for
> how it is used effectively.

Not a partucular test. But in a amoung current test modules under /libs
about 200 modules using test tools different from simple
BOOST_CHECK/BOOST_ASSERT

>> #define BOOST_TEST_MAIN
>> #include <boost/test/unit_test.hpp>
>>
>> BOOST_AUTO_TEST_CASE( t )
>> {
>> // here you go:
>> }
>>
>> Is this a hi barrier?
>
> It depends. Do I have to link with another library? If so, then add
> the lines of the Jamfile (and Jamfile.v2) to what I need to start
> with. What about allowing JIT debugging? Will this trap all my
> failures or can I get it to launch a debugger?

You could use

#include <boost/test/included/unit_test.hpp>

BOOST_AUTO_TEST_CASE( t )
{
// here you go:
}

No need for linking. Catching system error you could disable in either
Jamfile on in environment.

Gennadiy


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