[detail][lightweight_test.hpp] Proposal to add BOOST_TEST_THROWS to boost/detail/lightweight_test.hpp
Hi, In my tests I use boost/detail/lightweight_test.hpp as it has nearly all I need to test my libraries with very little overhead. However I needed a simple utility to check if an expression throws an exception and I think it can be added to this header with very little code. See attached patch. Do you find this a good idea? Ok to commit? Best, Ion
On 13 March 2013 20:03, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
In my tests I use boost/detail/lightweight_test.hpp as it has nearly all I need to test my libraries with very little overhead. However I needed a simple utility to check if an expression throws an exception and I think it can be added to this header with very little code. See attached patch.
Do you find this a good idea? Ok to commit?
Seems like a good idea. I'm not sure if you should use no_exceptions_support, since tests will always fail without exceptions.
El 13/03/2013 21:22, Daniel James escribió:
On 13 March 2013 20:03, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
In my tests I use boost/detail/lightweight_test.hpp as it has nearly all I need to test my libraries with very little overhead. However I needed a simple utility to check if an expression throws an exception and I think it can be added to this header with very little code. See attached patch.
Do you find this a good idea? Ok to commit?
Seems like a good idea. I'm not sure if you should use no_exceptions_support, since tests will always fail without exceptions.
You are right, I thought that in some compilers if "try" or "catch" is found with exceptions enabled, a compilation error could be triggered, but I guess that couldn't happen if try/catch is used in a preprocessor macro. Another option is to define the macro empty if BOOST_NO_EXCEPTIONS is defined, as the throwing expression would surely call a user defined abort mechanism (BOOST_ASSERT or similar) when BOOST_NO_EXCEPTIONS is defined. Or the user should protect BOOST_TEST_THROWS calls with #ifndef BOOST_NO_EXCEPTIONS macros. Best, Ion
Ion Gaztañaga wrote:
Another option is to define the macro empty if BOOST_NO_EXCEPTIONS is defined, as the throwing expression would surely call a user defined abort mechanism (BOOST_ASSERT or similar) when BOOST_NO_EXCEPTIONS is defined. Or the user should protect BOOST_TEST_THROWS calls with #ifndef BOOST_NO_EXCEPTIONS macros.
Both look sensible. As the user of the macro, what would you prefer? I'd think that in a BOOST_NO_EXCEPTIONS environment it's better to remove the test so that the rest could still be run. We don't actually test in such an environment so the question is a bit moot though.
El 13/03/2013 23:05, Peter Dimov escribió:
Ion Gaztañaga wrote:
Another option is to define the macro empty if BOOST_NO_EXCEPTIONS is defined, as the throwing expression would surely call a user defined abort mechanism (BOOST_ASSERT or similar) when BOOST_NO_EXCEPTIONS is defined. Or the user should protect BOOST_TEST_THROWS calls with #ifndef BOOST_NO_EXCEPTIONS macros.
Both look sensible. As the user of the macro, what would you prefer? I'd think that in a BOOST_NO_EXCEPTIONS environment it's better to remove the test so that the rest could still be run. We don't actually test in such an environment so the question is a bit moot though.
I've implemented a test for boost.container and I've found expanding BOOST_TEST_THROWS to nothing if BOOST_NO_EXCEPTIONS is defined is quite useful to maintain my test case clean. I only need to know that the expression won't be executed so if I call: BOOST_TEST_THROWS(c.reserve(100), std::exception) I can't write my test supposing "reserve" will be called. I think it's a good idea to avoid forcing users wrapping each BOOST_TEST_THROWS with #ifndef BOOST_NO_EXCEPTIONS/#endif. Patch attached with implementation and more comments. Ok to commit? Best, Ion
Ion Gaztañaga wrote:
Patch attached with implementation and more comments. Ok to commit?
This looks fine except that the comments for _EQ and _NE are reversed (the first says if expr1 == expr2 increases the error count, whereas expr1 != expr2 does) and the #include of no_exception_support.hpp should be removed.
El 14/03/2013 23:16, Peter Dimov escribió:
Ion Gaztañaga wrote:
Patch attached with implementation and more comments. Ok to commit?
This looks fine except that the comments for _EQ and _NE are reversed (the first says if expr1 == expr2 increases the error count, whereas expr1 != expr2 does) and the #include of no_exception_support.hpp should be removed.
Good catch, I'll change it and commit. Thanks, Ion
Another option is to define the macro empty if BOOST_NO_EXCEPTIONS is defined, as the throwing expression would surely call a user defined abort mechanism (BOOST_ASSERT or similar) when BOOST_NO_EXCEPTIONS is defined. Or the user should protect BOOST_TEST_THROWS calls with #ifndef BOOST_NO_EXCEPTIONS macros.
Both look sensible. As the user of the macro, what would you prefer? I'd think that in a BOOST_NO_EXCEPTIONS environment it's better to remove the test so that the rest could still be run. We don't actually test in such an environment so the question is a bit moot though.
I've implemented a test for boost.container and I've found expanding BOOST_TEST_THROWS to nothing if BOOST_NO_EXCEPTIONS is defined is quite useful to maintain my test case clean. I only need to know that the expression won't be executed so if I call:
BOOST_TEST_THROWS(c.reserve(100), std::exception)
I can't write my test supposing "reserve" will be called. I think it's a good idea to avoid forcing users wrapping each BOOST_TEST_THROWS with #ifndef BOOST_NO_EXCEPTIONS/#endif. Patch attached with implementation and more comments. Ok to commit?
That sounds like a good idea to me. BTW, I wrote something similar myself which contains almost all of the Boost.Test testing macros, but depends only on the lightweight test header - I'm attaching what I ended up with - do whatever you want with it ;-) John.
El 15/03/2013 12:08, John Maddock escribió:
BTW, I wrote something similar myself which contains almost all of the Boost.Test testing macros, but depends only on the lightweight test header - I'm attaching what I ended up with - do whatever you want with it ;-)
Very interesting, thanks for sharing this. Best, Ion
participants (4)
-
Daniel James -
Ion Gaztañaga -
John Maddock -
Peter Dimov