Boost.Container and tests: why is Boost.Test bypassed
Hi Ion, I have a GSOC student writing some containers that fit naturally into Boost.Container. So he tries to do things the way that you have done, which is fine. I do wonder why the tests are written with assertions and not using Boost.Test? Is it a dependency problem or? Thanks -Thorsten
El 01/06/2015 a las 20:48, Thorsten Ottosen escribió:
Hi Ion,
I have a GSOC student writing some containers that fit naturally into Boost.Container. So he tries to do things the way that you have done, which is fine.
I do wonder why the tests are written with assertions and not using Boost.Test? Is it a dependency problem or?
Those test were inherited from Boost.Interprocess and when trying Boost.Test back in 2005 I found it too heavyweight for the kind of tests I needed, specially when using the debugger. It could an old problem with my IDE installation but I never looked back. After some years I've slowly started porting some tests from my libraries (maybe not Container, I can't remember) to Core's lightweight_test which I is dependecy-free, fast and enough for most needs: http://www.boost.org/boost/core/lightweight_test.hpp Is lightweight test acceptable for GSOC? Best, Ion
On 2 Jun 2015 at 18:56, Ion Gaztañaga wrote:
I have a GSOC student writing some containers that fit naturally into Boost.Container. So he tries to do things the way that you have done, which is fine.
I do wonder why the tests are written with assertions and not using Boost.Test? Is it a dependency problem or?
Those test were inherited from Boost.Interprocess and when trying Boost.Test back in 2005 I found it too heavyweight for the kind of tests I needed, specially when using the debugger. It could an old problem with my IDE installation but I never looked back.
Turning off header only mode in Boost.Test makes the heaviness go away, but breaks build on some less common platforms.
After some years I've slowly started porting some tests from my libraries (maybe not Container, I can't remember) to Core's lightweight_test which I is dependecy-free, fast and enough for most needs:
http://www.boost.org/boost/core/lightweight_test.hpp
Is lightweight test acceptable for GSOC?
Yes it is. I am personally opposed to lightweight test because it does not integrate well with test results aggregation tooling, and therefore should not be used in new code. More explanation is at: https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a9.MAINTENA NCE:ConsidermakingitpossibletouseanXMLoutputtingunittestingframeworkev enifnotenabledbydefault Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
I am personally opposed to lightweight test because it does not integrate well with test results aggregation tooling, and therefore should not be used in new code.
What would it take for lightweight_test to be changed to integrate well? I did read your "more explanation" but it didn't answer this question.
On 2 Jun 2015 at 23:10, Peter Dimov wrote:
I am personally opposed to lightweight test because it does not integrate well with test results aggregation tooling, and therefore should not be used in new code.
What would it take for lightweight_test to be changed to integrate well?
I did read your "more explanation" but it didn't answer this question.
I don't consider there to be any need for lightweight_test in new code when you have a choice between the very capable Boost.Test and its emulation based on CATCH. One test code can do both on a compile time switch, or indeed simply use assert. However, seeing as you ask, I think it was Steven who told me at C++ Now that apparently Boost.Build has the ability to spit out XML for whether individual test programs pass or fail, and from that I would imagine a XSLT could generate JUnit XML. So I guess that facility would just need to be finished and documented, and you're good to go. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 02-06-2015 18:56, Ion Gaztañaga wrote:
El 01/06/2015 a las 20:48, Thorsten Ottosen escribió:
Hi Ion,
I have a GSOC student writing some containers that fit naturally into Boost.Container. So he tries to do things the way that you have done, which is fine.
I do wonder why the tests are written with assertions and not using Boost.Test? Is it a dependency problem or?
Those test were inherited from Boost.Interprocess and when trying Boost.Test back in 2005 I found it too heavyweight for the kind of tests I needed, specially when using the debugger. It could an old problem with my IDE installation but I never looked back.
After some years I've slowly started porting some tests from my libraries (maybe not Container, I can't remember) to Core's lightweight_test which I is dependecy-free, fast and enough for most needs:
Thanks for explaining. I think then I will recommend my student that normal Boost.Test testing is done. I haven't found any problems with using the debugger (on windows) with Boost.Test. cheers -Thorsten
Ion Gaztañaga
Those test were inherited from Boost.Interprocess and when trying Boost.Test back in 2005 I found it too heavyweight for the kind of tests I needed, specially when using the debugger. It could an old problem with my IDE installation but I never looked back.
After some years I've slowly started porting some tests from my libraries (maybe not Container, I can't remember) to Core's lightweight_test which I is dependecy-free, fast and enough for most needs:
Not to bead the dead horse, but I'll continue to object to any unqualified
statements about this misconception that this header is any more
lightweight than Boost.Test.
Consider this example:
#include
El 03/06/2015 a las 0:02, Gennadiy Rozental escribió:
Not to bead the dead horse, but I'll continue to object to any unqualified statements about this misconception that this header is any more lightweight than Boost.Test.
Gennadiy, I didn't want to make any false claim, sorry if I expressed something that might misguide any reader. I used the library a lot of years ago, and for some reason (maybe my own misunderstanding problems), I thought it was more that I needed/wanted and other alternatives looked easier to me, that's what I wanted to say with "heavyweight"). Maybe it was a bad decision, maybe it was biased by my limited hardware. Thanks for your explanations, Best, Ion
On 2 Jun 2015 at 22:02, Gennadiy Rozental wrote:
Not to bead the dead horse, but I'll continue to object to any unqualified statements about this misconception that this header is any more lightweight than Boost.Test.
As you can see Boost.Test version is at least as simple. On majority of modern hardware it takes as much time to build. And I am not even going to list all the other advantages (better log and report and so on) Boost.Test version has.
I read him as meaning Boost.Test is heavy on build times, which it is when in header only mode which is the default. If header only is disabled, I found the effect on build times very reasonable for the power of the library's facilities. I personally wish header only were default off in Boost.Test. Has any work been done on build time for Boost.Test v3? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
AMDG On 06/02/2015 06:07 PM, Niall Douglas wrote:
I read him as meaning Boost.Test is heavy on build times, which it is when in header only mode which is the default.
Last time I checked, Boost.Test is only
header-only if you #include
On 2 Jun 2015 at 18:24, Steven Watanabe wrote:
I read him as meaning Boost.Test is heavy on build times, which it is when in header only mode which is the default.
Last time I checked, Boost.Test is only header-only if you #include
instead of the regular headers.
Yes, you're right. And anything inside included/* is obviously not the default. Thanks for the catch. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas
Has any work been done on build time for Boost.Test v3?
I would not expect faster build time. That said on my two years old windows laptop build step takes maybe half a second on a simple test module (can't say for sure - it is actually too fast to notice). I would be interested to see some statistics about other people experience. That said, no one forces you to sue included version. It is your decision which variant to use. You need to about a minute to produce a library and many Linux systems might have it around already. Gennadiy
2015-06-03 0:02 GMT+02:00 Gennadiy Rozental
Ion Gaztañaga
writes: Those test were inherited from Boost.Interprocess and when trying Boost.Test back in 2005 I found it too heavyweight for the kind of tests I needed, specially when using the debugger. It could an old problem with my IDE installation but I never looked back.
After some years I've slowly started porting some tests from my libraries (maybe not Container, I can't remember) to Core's lightweight_test which I is dependecy-free, fast and enough for most needs:
Not to bead the dead horse, but I'll continue to object to any unqualified statements about this misconception that this header is any more lightweight than Boost.Test.
Consider this example:
#include
int main() { int object1 = 1; int object2 = 2;
boost::swap(object1,object2);
BOOST_TEST(object1 == 2); BOOST_TEST(object2 == 1);
return boost::report_errors(); }
and compare with Boost.Test version:
#define BOOST_TEST_MODULE my test #include
BOOST_AUTO_TEST_CASE(trivial_swap) { int object1 = 1; int object2 = 2;
boost::swap(object1,object2);
BOOST_TEST(object1 == 2); BOOST_TEST(object2 == 1); }
As you can see Boost.Test version is at least as simple. On majority of modern hardware it takes as much time to build. And I am not even going to list all the other advantages (better log and report and so on) Boost.Test version has.
Furthermore, most developer do need at least some form of test organization. See for example boost sources where lightweight_test.hpp is used. You will find many cases that look like this:
....
int main() { test<1>(); test<2>(); test<4>(); test<8>(); test<16>(); test<32>(); test<64>(); test<128>();
return boost::report_errors(); }
OR
...
int main() { test_integral(); test_floating_point(); test_nullptr_t(); test_pointer(); test_member_pointer(); test_enum(); test_class();
return boost::report_errors(); }
Boost.Test based test modules would have look simpler in these cases, provide better error attribution and many many more other thing.
You are free to use anything for your unit test, but if you are making claims please back them up.
Just note that Boost.Test v3 for the moment is not an option when testing in branch master. Luckily, it is going to be, soon. Regards, &rzej
participants (7)
-
Andrzej Krzemienski -
Gennadiy Rozental -
Ion Gaztañaga -
Niall Douglas -
Peter Dimov -
Steven Watanabe -
Thorsten Ottosen