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