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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2007-05-16 09:25:00

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.

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.

> 
> > 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.

> 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
-- deprecated previously, and removed now -- no real argument there
except the lack of documentation with the release).  However, all our
tests that use the framework instead of auto-tests have to change.

> 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.

> > 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.

> 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.

> 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.

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
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.

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.

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.

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.