Re: [boost] [Test] boost_unit_test_framework and main()

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-16 11:14:26

"Jody Hagins" <jody-boost-011304_at_[hidden]> wrote in message 
news:20070516092500.59f0ebd0.jody-boost-011304_at_atdesk.com...
> On Wed, 16 May 2007 02:41:08 -0400
> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote:
>
>
>> > We now need to define BOOST_TEST_DYN_LINK in the appropriate build
>> > files
>>
>> Only if you use dynamic version of the UTF. But this is common
>> requirements  of all boost libraries.
>
> Odd, then, that we've been using many parts of boost for years, and this
> is the first time we've encountered this "common requirement."  We are
> not doing anything special in this case, and the sad part is that our
> existing tests break.

BOOST_ALL_DYN_LINK or BOOST_<lib>_DYN_LINK are required for dynamic library 
compilation of any library.
It worked on *nix machines before cause it happends thhat there is no 
difference in usage semantic for both variants.

> Again, I reiterate, it is NOT a good thing that we have to rewrite our
> tests just to see if our code works with the latest release of boost.

I don't believe you have to.

>
>>
>> > We now have to define BOOST_TEST_MAIN in all our test programs that
>> > used to get main() by simply linking to the shared library.  That's
>> > a LOT of source files to change.
>>
>> That's not true. Or rather mostly not true. If you used to use static
>> library and continue using it no change required. If you used shared
>> library
>
> Our tests link against the shared library, since that's what you get by
> default on *nix systems.  The change breaks all existing tests.

Boost.Test by default is configured to be used with static library variant. 
To use dynamic library variant you need to define above flag.

>> variants and had BOOST_TEST_AUTO_MAIN no change required either. If
>> you used
>
> Not true.  According to the old documentation, we used
> BOOST_TEST_AUTO_MAIN only in the cases where we were using AUTO_TEST,
> which we had to change to BOOST_TEST_CASE (or some similar incantation

BOOST_AUTO_TEST_CASE

> -- deprecated previously, and removed now -- no real argument there
> except the lack of documentation with the release).

I did not get from above. Why do you say "Not True"? Do you mean that your 
test modules linked with dynamic library variant and BOOST_AUTO_TEST_CASE 
fails. It shouldn't. Did you define BOOST_TEST_DYN_LINK somewhere in your 
make file?

> However, all our
> tests that use the framework instead of auto-tests have to change.

Yes. Or you could switch to static library variant and make no changes.

>> dynamic library and did not define above flag you have much bigger
>> problem.  you test module won't compile at all. The initialization
>> function signature  is changed.
>
>
> Hmmm. I have not experienced the problem you specify.  We used
> BOOST_TEST_AUTO_MAIN for the tests that used the auto-test features, and
> did not use it for tests that were not auto-tests...  for those, we
> simply defined our own test_main or whatever it is called.

That's because you did not define BOOST_TEST_DYN_LINK.

>> > In summary, I have to change EVERY SINGLE test program in my company
>> > that uses Boost.Test and does not use auto-test (though I probably
>> > need to change those as well, because that feature is deprecated...
>> > though still supported)... and EVERY SINGLE makefile that builds
>> > them.
>>
>> What do you mean? Automatic registration facilities are not only still
>>
>> supported in a scope thay were defined in 1.33.1, but in fact
>> significantly  improved and extended. I personally recommend moving
>> all your test modules  to this facilties. As for the test modules that
>> employ manual registraition  and static library variant, my
>> understanding is that they worked my chance.
>
> I do not understand the above paragaph.

My point is that "the feature is depricated" statement is not correct. 
Auto-registration facilities are live and well. Even better than before.

>
>> You "thought" you are linking with static library, while in fact you
>> linked
>
> No, I've been developing on *nix systems for over 25 years.  I actually
> built the ELF support for an SVr4 variant years ago.  I *knew* I was
> linking with the dynamic library.  That's what I expected, and it is
> what I got.  I have a bunch of tests, and linking them all with the
> static library uses a lot of extra disk space.  I DO NOT want to link
> with the static library.
>
> For me, there are only two reasons I want to link with a static library,
> and neither of them revolves around the notion that a function lives in
> the static lib but not the dynamic lib.

In a short term you may opt to use static library variant for the test 
modules that are using manual registration. If you do insist on using 
dynamic library the change is an order.  Here is an example from my 
presentation:

#define BOOST_TEST_DYN_LINK
#include <boost/test/unit_test.hpp>
#include <boost/bind.hpp>
using namespace boost::unit_test;
void free_test_function( int i, int j )
{
    BOOST_CHECK( true /* test assertion */ );
}

bool
init_function() {
     framework::master_test_suite().
        add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 1 ) ) );
     framework::master_test_suite().
        add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 2 ) ) );
     framework::master_test_suite().
        add( BOOST_TEST_CASE( boost::bind( &free_test_function, 2, 1 ) ) );

     return true;
}

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

>> with shared one. The only change is required for test modules that
>> employ  manual registration and dynamic library variant. 1.34.0 allows
>> you now to  build these on NT without any code change. But you are
>> required to make it  conformant with new initalization function
>> specification and implement  function main() manually. I am showing
>> example of how it's done on my Friday  session.
>
>
> Again, I must be missing something.  Most of our tests conform to one of
> two models.  Auto-tests, which look like this (prior to necessary code
> changes to conform with 1.34)...
>
> #define BOOST_AUTO_TEST_MAIN
> #include <boost/test/auto_unit_test.hpp>
>
> // A number of tests, similar to this
> BOOST_AUTO_UNIT_TEST(default_normalize_test)
> {
>  // ...
> }
>
>
>
> For these tests, we had to change BOOST_AUTO_UNIT_TEST to
> BOOST_TEST_CASE, and then we got linker errors.  We then had to add
> -DBOOST_TEST_DYN_LINK to the makefiles.

And it starter to work, yes?

> Our other variant (which is much more popular) is this pattern...
>
>
> #include "boost/test/unit_test.hpp"
>
> // A bunch of test code
>
> test_suite *
> init_unit_test_suite(int, char * [])
> {
>  test_suite * ts = BOOST_TEST_SUITE("simple_format_ut");
>  // A number of test_suite method calls
>  return ts;
> }
>
>
>
> For all of these tests, we had to add #define BOOST_TEST_MAIN to each

This is plain wrong. BOOST_TEST_MAIN has nothing to do with test modules 
that employ manual registration.

> file (well, we could not add it to all files, we had to pick one that
> would be the "main" and add it there because we link several files into
> one test executable).  We also had to add the -DBOOST_TEST_DYN_LINK flag
> in the compiler line.

And you should see an error indicating that there is no function main()

> Personally, I think this is a terrible solution.  I am not a windows
> person, so I'm not sure what other options exist.  I understand putting
> link-time stuff into a compile of object files that are going into a
> shared library.  However, it makes no sense for executables.  I like
> running my final tests of my own code with both dynamic and shared
> libraries.  This way, I know I didn't build one wrongly.  Using
> Boost.Test, however, I now have to compile different variants depending
> on whether I want to link with a static library or a shared library.  To
> me, that is wrong and unacceptable...  aside from the fact that it
> breaks my existing tests.

Do you know any other way to make dynamic library work portably?

> Let me restate that...  I have come to accept the fact that our tests
> are going to change with almost every release of boost.  My colleagues
> have not accepted it... mostly because they have to do most of the work,
> and I don't.  However, the whole concept of compiling code based on
> linking with a static or dynamic library is just plain wrong.

I dont expect any breaking changes any more. The reason this was changes is 
because dynamiclibrary support was broken and half baked.

> If you are trying for consistency, then I'd be more in favor of removing
> main() completely from the libraries than requiring different
> compilation flags depending on how it would be linked.

I considerred this option. But this would require users of static library 
and manual registraition (and they are majority for now from what I 
understand) to implement function main() explicetly similar to an example 
above. I did make an effort to minimize an impact. If you use automated 
registration (which you should try to anyway, there very small number of 
cases where you cant) the new dynamic library support works without any 
changes.

Gennadiy