"David Abrahams" <dave@boost-consulting.com> wrote in message news:uzmh2488y.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
For me, barriers to writing tests have to be extremely low, because I just have too many other things to think about.
I worked very hard on usebility last couple releases. I don't see how it could be done easier for users at the moment.
I think that job isn't finished yet. I keep hearing from people who try to use the test library and are frustrated (I'm sorry, I'm not naming my sources).
Could you at least present reasons for their frustration?
For example:
anonymous: why do i need a separate .lib?
It's optional. You could always use "included" variant.
anonymous: <sigh>
?
anonymous: my needs are very simple anonymous: boost.test is too complicated
This is not a reason. This this an outcome. What is complicated?
anonymous: the minimal test framework met my needs
Unit Test Framework does the same with smaller typing: #include <boost/test/minimal.hpp> int test_main( int /*argc*/, char* /*argv*/[] ) { int i = 1; BOOST_CHECK( i == 1 ); return 0; } vs. #define BOOST_TEST_MODULE my_test #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_CASE( test_main ) { int i = 1; BOOST_CHECK( i == 1 ); } So this point is invalid here IMO.
That's what I am trying to say is the best solution IMO - set it up in either tool or testing.jam
Great, but...
I think, to the extent to which an interaction with Boost.Test behavior causes the problem, the information about how to set the options should be maintained with Boost.Test. Also, it should be included in the Boost.Test documentation, because Boost won't be the only project with the same issues.
Yes this need to be covered in docs.
...given that fact, it seems obvious to me that the test library maintainer should take responsibility for maintaining that setting in the build/test framework.
Unfortunately I don't know Boost Build enough to be able to do this. Gennadiy