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