Re: [boost] Boost.Tests: Unit test defines own main() function, why?

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2007-12-21 02:51:40

"Jens Seidel" <jensseidel_at_[hidden]> wrote in message 
news:20071220161635.GA515_at_imkf-pc073.imkf.tu-freiberg.de...
> Hi,
>
> I know it may no longer fit on this list but as I started here let's not
> move the list ...
>
> I read most of the new documentation but to make it short: I still fail
> to use unit tests. It worked in the past but after a lot of changes
> in Boost.Tests it is now unusable for me.

Let's  see concrete examples.

>> > >  * According to 
>> > > http://lists.boost.org/Archives/boost/2007/05/121601.php
>> > >    linkers don't look into libraries (either static or dynamic) to
>> > >    find main so that unit tests cannot be cimpiled as shared library.
>
>> > It's not a bug. It's a feature. ;) Starting 1.34.1 main() doesn't 
>> > reside in
>> > shared libs.
>
>> > In any case Boost.Test supports
>> > what you want. In many, many cases you don't need init_.. function 
>> > anymore and
>> > boost test provides a way for users to get away without it and function 
>> > main()
>> > as well both with static and shared library usage variant of the UTF. 
>> > If you
>>
>> OK. This is probably preferred.
>
> But now I wonder why I should make a lot of incompatibles changes? I
> want my program and all tests beeing able to compile everywhere with
> (nearly) all versions of Boost.
>
> Using some small code parts condionally depending on autotools system
> and Boost tests (version of boost, shared library is available?, ...)
> would be acceptable but I'm no willing to make major changes to my code.

You shouldn't be required.

>> > prefer to define main youself and invoke init function you can do it as 
>> > well
>> > with shared library variant.
>
> And how?

See example 9 on

http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/manual-nullary-test-case.html

> Including the header boost/test/included/unit_test.hpp *once* per binary 
> seems
> to work but normal using of boost/test/unit_test.hpp together with an 
> additional
> #define BOOST_TEST_DYN_LINK
> still leads to a missing main() function. I get since 1.34.1:
> /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function 
> `_start':
> (.text+0x18): undefined reference to `main'
> collect2: ld returned 1 exit status

You also need to define either BOOST_TEST_MODULE or BOOST_TEST_MAIN if you 
want Boost.Test to generate main function for you. Like in an example 18 
here:

http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/master-test-suite.html

> I defined also a dummy main function (just to make the linker happy as I
> assumed the tests are maybe started in the contructor of a static 
> variable) but
> my test is not called. Even calling init_unit_test_suite() from main() 
> does not
> work.

You need to call a test runner not init function. See example 9 above.

> I also defined BOOST_TEST_DYN_LINK on the comandline to ensure that all 
> code
> uses it. Same result! Defining addionally BOOST_TEST_MAIN results in a
> a proper empty test with the output
> "Test setup error: test tree is empty"

Because BOOST_TEST_MAIN produces both function main and empty init function. 
It's assumed that test units are automatically registered.

> I thought I have also seen a conflict with my own init_unit_test_suite()
> implementation if I define BOOST_TEST_MAIN but cannot reproduce it.

There would be a compile time error if you follow proper signature of init 
function for use with shared library.

> A question: Would it be save to define BOOST_TEST_DYN_LINK also for static
> linkage?

No.

> I hope so as I have never, really never used different code depending on 
> linker options.

We have to be tollerant to guest from other continents. Our policies 
selected to work the same way for every one.

> Even after renaming my main
> test_suite* init_unit_test_suite(int, char *[])
> function into
> bool init_unit_test()
> (but only for dynamic linkage?) as noticed on
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
> I fail as usual.

You should see compilation errors now.

> Short: In the past it was so simple:
>
> #include <boost/test/unit_test.hpp>
> using boost::unit_test::test_suite;
> test_suite* init_unit_test_suite(int, char *[])
> {
>   test_suite *test = BOOST_TEST_SUITE("Master test suite");
>   test->add(BOOST_TEST_CASE(&JacobiTest1));
>   return test;
> }
>
> Now I use
>
> * Additional autoconf code to define HAVE_UNIT_TEST_LIB if the (shared?) 
> library is
>  used.
>
> #ifdef HAVE_CONFIG_H
> #include <config.h> // HAVE_UNIT_TEST_LIB
> #endif
>
> #ifdef HAVE_UNIT_TEST_LIB
> #  define BOOST_TEST_DYN_LINK
> #  include <boost/test/unit_test.hpp>
> #else
> #  include <boost/test/included/unit_test.hpp>
> #endif

1. You can use static library and no need to define BOOST_TEST_DYN_LINK for 
either library of included variant
2. You can use included variant always
3. You can switch to automated registration and you don't need to define nor 
function main(), nor init function

> using boost::unit_test::test_suite;
>
> bool init_unit_test()
> {
>  // my old init_unit_test_suite code
> }
>
> /*
> int main(int argc, char *argv[])
> {
>  init_unit_test_suite(argc, argv);
>  return 0;
> }
> */

If you insist on combination of manual registration with shared library, it 
should look like this:

int
main( int argc, char* argv[] )
{
    return ::boost::unit_test::unit_test_main( &init_unit_test, argc, 
argv );
}

> the required information is wrong and incomplete and addionally

What is wrong?

> scattered across multiple pages such as
> http://www.patmedia.net/~rogeeff/html/utf/compilation.html
> http://www.patmedia.net/~rogeeff/html/utf/compilation/direct-include.html
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants.html
> (and all referenced sub pages)
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-runners.html
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html

If you can express it all better I am open to sugestions. It is indeed not 
very trivial (considering many different usage variant of Boost.Test) to 
describe all necessary information and be both complete and easily 
accessible to first timers.

> To show you that I really read (at least up to UTF) the documenation I 
> mention
> a few errors in it:

I'll look on these later.

Thanks for the comments

Gennadiy