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

From: Ilya Sokolov (fal_delivery_at_[hidden])
Date: 2007-12-24 06:33:18

Gennadiy Rozental wrote:
> "Ilya Sokolov" <fal_delivery_at_[hidden]> wrote in message 
> news:fkg1cd$gdv$1_at_ger.gmane.org...
>> Sorry for breaking into discussion but I have a bunch of related 
>> questions.
>>
>> Gennadiy Rozental wrote:
>>> "Jens Seidel" <jensseidel_at_[hidden]> wrote in message
>> [snip]
>>> Because BOOST_TEST_MAIN produces both function main and empty init 
>>> function.
>>> It's assumed that test units are automatically registered.
>> Why both? Also, why defining BOOST_TEST_DYN_LINK switches on
>> BOOST_TEST_ALTERNATIVE_INIT_API?
> 
> 1. Because alternatively I would've required 90% of the users to define 2 
> pretty closely names macro: BOOST_TEST_MAIN to define init function (this is 
> what this macro always did, so I can't change the meaning) 

In my opinion, BOOST_TEST_MAIN is a misleading name because it produces 
not only the main() function.

> plus another one 
> BOOST_TEST_MAIN_FUNCTION that will actually produce the function main()

> 2. Unfortunately original test modult function signature is unacceptable for 
> DLL initialization. So i had to introduce new one.

I don't see it unacceptable, given the majority of 
init_unit_test_suite() functions using BOOST_TEST_SUITE macro. I think 
BOOST_ALTERNATIVE_INIT_API should be default, but not the requirement 
for dynamic builds. And maybe it should be default for static builds 
also, because now it is recommended to use "master test suite".

>> Suppose I need to perform some initialization call, e.g.
>> boost::filesystem::initial_path(). Currently, with shared Boost.Test I
>> am forced to not to define BOOST_TEST_MAIN and to copy/paste the main()
>> function like this:
>>
>> int BOOST_TEST_CALL_DECL main(int argc, char* argv[])
>> {
>>     return boost::unit_test::unit_test_main(&init_unit_test, argc, argv);
>> }
> No. I don't think this is the best approach. Much better (and shorter) 
> solution is
> 
> struct init {
>     init() { boost::filesystem::initial_path(); }
> }
> 
> BOOST_GLOBAL_FIXTURE( init );

I see this much cleaner:

#ifdef BOOST_TEST_DYN_LINK
# define BOOST_TEST_MAIN_FUNCTION
#endif
#include <boost/test/unit_test.hpp>

bool init_unit_test()
{
   boost::filesystem::initial_path();
   return true;
}

>> Now if I want to support using static Boost.Test, I am forced to define
>> BOOST_TEST_ALTERNATIVE_INIT_API.
> 
> I always find it confusing: why would you want to support both static and 
> shared libraries?

Why not???

> Pick one more convinient for you and stick with it. It's
> not like you need to test your test module with all variants of Boost.Test 
> framework. It's your own test, not the test for the UTF. All in all I find 
> an effort for simultanious support for both static and shared variant of the 
> UTF a bit misguided.

I want to seamlessly migrate from static UTF to shared. I need to 
fallback to the static UTF where it is not supported (by toolchain).

> Gennadiy