[test] Fixtures and Documentation
Hi Everyone, I've been using Boost.Test for a while already, and although I do think it's a very powerful library, it is a little unweildy to navigate the documentation of the library. For example, currently in the online documentation, links to the examples don't work correctly and there are areas which lead to "404" messages. The question is really simple though: when using BOOST_AUTO_TEST_CASE, how do I cut down on repetitive code and set up "fixtures"? For example, set up variables that are common in all test case bodies in the same file? I'm pretty confident there should be a way to do this -- and if there is, where do I find documentation on it? For now I'll resort to header-reading to find out how to use the macros, though it would be nice to have a one-stop library reference or guide for Boost.Test. TIA -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Hi Dean, Take a look at libs/test/example/unit_test_example_07.cpp for suite level fixtures (for your case below) and libs/test/example/unit_test_example_09_1.cpp for global level fixtures. The docs on patmedia.com disappeared over weekend but Gennadiy is finding a new home for it. Regards, Bruce Dean Michael Berris wrote:
Hi Everyone,
I've been using Boost.Test for a while already, and although I do think it's a very powerful library, it is a little unweildy to navigate the documentation of the library. For example, currently in the online documentation, links to the examples don't work correctly and there are areas which lead to "404" messages.
The question is really simple though: when using BOOST_AUTO_TEST_CASE, how do I cut down on repetitive code and set up "fixtures"? For example, set up variables that are common in all test case bodies in the same file?
I'm pretty confident there should be a way to do this -- and if there is, where do I find documentation on it?
For now I'll resort to header-reading to find out how to use the macros, though it would be nice to have a one-stop library reference or guide for Boost.Test.
TIA
Hi Bruce, On Wed, Jul 23, 2008 at 9:12 PM, Bruce Trask <bruce.trask@mdesystems.com> wrote:
Hi Dean,
Take a look at libs/test/example/unit_test_example_07.cpp for suite level fixtures (for your case below) and libs/test/example/unit_test_example_09_1.cpp for global level fixtures.
Thanks, I've elected to convert my tests to use BOOST_FIXTURE_TEST_CASE ( testname, fixture_class_name ) instead. Now though, everything looks redundant because I have to put the name of the fixture class everywhere I have BOOST_FIXTURE_TEST_CASE (...). I notice that there's a global level fixtures, but I'm more interested in something that get constructed/destroyed with every test case invocation -- much like the setUp() and tearDown() overloads in the xUnit family of frameworks. I looked at the implementation of BOOST_AUTO_TEST_CASE (...) and saw that it deferred to BOOST_FIXTURE_TEST_CASE (...). Would it then be possible to define the class name of the BOOST_AUTO_TEST_FIXTURE class, instead of being defaulted to an empty class?
The docs on patmedia.com disappeared over weekend but Gennadiy is finding a new home for it.
Okay, why isn't the docs for Boost.Test not part of the 1.35.0 release though? Is this a separate set of documentation you're referring to? -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Thanks, I've elected to convert my tests to use BOOST_FIXTURE_TEST_CASE ( testname, fixture_class_name ) instead. Now though, everything looks redundant because I have to put the name of the fixture class everywhere I have BOOST_FIXTURE_TEST_CASE (...).
Use BOOST_FIXTURE_TEST_SUITE and all test cases inside this test suite will get fixture automatically (see unit_test_example_07.cpp for example)
I notice that there's a global level fixtures, but I'm more interested in something that get constructed/destroyed with every test case invocation -- much like the setUp() and tearDown() overloads in the xUnit family of frameworks.
The fixtures *are* constructed/destroyed per test case. Gennadiy
On Thu, Jul 24, 2008 at 1:17 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Thanks, I've elected to convert my tests to use BOOST_FIXTURE_TEST_CASE ( testname, fixture_class_name ) instead. Now though, everything looks redundant because I have to put the name of the fixture class everywhere I have BOOST_FIXTURE_TEST_CASE (...).
Use BOOST_FIXTURE_TEST_SUITE and all test cases inside this test suite will get fixture automatically (see unit_test_example_07.cpp for example)
Okay, but it's not clear from this example whether using just the normal BOOST_AUTO_TEST_CASE ( test_name ) would work with the correct fixture type set using BOOST_FIXTURE_TEST_SUITE. Even in the example, BOOST_FIXTURE_TEST_SUITE (s,F) doesn't really convey much information except maybe (I'm guessing) create a fixture test suite 's' of type F. It isn't directly obvious how doing BOOST_FIXTURE_TEST_SUITE (...) will actually influence all BOOST_AUTO_TEST_CASE(s) (or in the example BOOST_AUTO_TEST_CASE_TEMPLATE) in the file. Perhaps using a convention like "do `#define BOOST_AUTO_TEST_FIXTURE fixture_type_name` before including 'boost/test/unit_test.hpp'" would work too and be more convenient -- especially in cases where you have a family of related tests in one file. That way you just did: #ifndef BOOST_AUTO_TEST_FIXTURE #define ... #endif in the library to use what the user intended. That way it was less intrusive than having to create a test suite when all you really have are a collection of test cases in a test file. Of course I may be missing some things, but now that I know about BOOST_FIXTURE_TEST_SUITE, I'll use that in the meantime. :D
I notice that there's a global level fixtures, but I'm more interested in something that get constructed/destroyed with every test case invocation -- much like the setUp() and tearDown() overloads in the xUnit family of frameworks.
The fixtures *are* constructed/destroyed per test case.
Even the global fixture? I was under the impression that the global fixture would be something that would be created/destroyed at the start/end of the program -- more like a program-global fixture. Did I misunderstand the implication of the term global fixtures? Thanks for the response, and I look forward to using this library more! -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Thanks, I've elected to convert my tests to use BOOST_FIXTURE_TEST_CASE ( testname, fixture_class_name ) instead. Now though, everything looks redundant because I have to put the name of the fixture class everywhere I have BOOST_FIXTURE_TEST_CASE (...).
Use BOOST_FIXTURE_TEST_SUITE and all test cases inside this test suite will get fixture automatically (see unit_test_example_07.cpp for example)
Okay, but it's not clear from this example whether using just the normal BOOST_AUTO_TEST_CASE ( test_name ) would work with the correct fixture type set using BOOST_FIXTURE_TEST_SUITE.
Yes. It will. Give it a try.
Even in the example, BOOST_FIXTURE_TEST_SUITE (s,F) doesn't really convey much information
New docs have much better examples
except maybe (I'm guessing) create a fixture test suite 's' of type F. It isn't directly obvious how doing BOOST_FIXTURE_TEST_SUITE (...) will actually influence all BOOST_AUTO_TEST_CASE(s) (or in the example BOOST_AUTO_TEST_CASE_TEMPLATE) in the file.
You don't need to know how. It just works ;) But if you are interested you can always look in the headers where it's implemented
Perhaps using a convention like "do `#define BOOST_AUTO_TEST_FIXTURE fixture_type_name` before including 'boost/test/unit_test.hpp'" would work too and be more convenient -- especially in cases where you have a family of related tests in one file. That way you just did:
#ifndef BOOST_AUTO_TEST_FIXTURE #define ... #endif
I do not see why we need this and how is it better than the solution currently implemented in the library
in the library to use what the user intended. That way it was less intrusive than having to create a test suite when all you really have are a collection of test cases in a test file.
I do not see why creating test suite is intrusive
Of course I may be missing some things, but now that I know about BOOST_FIXTURE_TEST_SUITE, I'll use that in the meantime. :D
Give it a try and let me know if you have any problems
I notice that there's a global level fixtures, but I'm more interested in something that get constructed/destroyed with every test case invocation -- much like the setUp() and tearDown() overloads in the xUnit family of frameworks.
The fixtures *are* constructed/destroyed per test case.
Even the global fixture? I was under the impression that the global
No. Global fixtures are constructed/destructor pre post whole testing process. Gennadiy
On Thu, Jul 24, 2008 at 3:45 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Okay, but it's not clear from this example whether using just the normal BOOST_AUTO_TEST_CASE ( test_name ) would work with the correct fixture type set using BOOST_FIXTURE_TEST_SUITE.
Yes. It will. Give it a try.
Sounds encouraging. :-) I will. Thanks.
Even in the example, BOOST_FIXTURE_TEST_SUITE (s,F) doesn't really convey much information
New docs have much better examples
Can hardly wait to read those.
except maybe (I'm guessing) create a fixture test suite 's' of type F. It isn't directly obvious how doing BOOST_FIXTURE_TEST_SUITE (...) will actually influence all BOOST_AUTO_TEST_CASE(s) (or in the example BOOST_AUTO_TEST_CASE_TEMPLATE) in the file.
You don't need to know how. It just works ;) But if you are interested you can always look in the headers where it's implemented
Right. I looked into it but I was a little hazy with the details. I'll look deeper if I need to find out more. :D
Perhaps using a convention like "do `#define BOOST_AUTO_TEST_FIXTURE fixture_type_name` before including 'boost/test/unit_test.hpp'" would work too and be more convenient -- especially in cases where you have a family of related tests in one file. That way you just did:
#ifndef BOOST_AUTO_TEST_FIXTURE #define ... #endif
I do not see why we need this and how is it better than the solution currently implemented in the library
It isn't better, it's an alternative that is convenient compared to setting up a test suite.
in the library to use what the user intended. That way it was less intrusive than having to create a test suite when all you really have are a collection of test cases in a test file.
I do not see why creating test suite is intrusive
It's intrusive in terms of style -- having to think about the test suite when all you need is test cases with fixtures at the simplest way. But of course there's always different strokes for different folks.
Of course I may be missing some things, but now that I know about BOOST_FIXTURE_TEST_SUITE, I'll use that in the meantime. :D
Give it a try and let me know if you have any problems
I will. Thanks.
I notice that there's a global level fixtures, but I'm more interested in something that get constructed/destroyed with every test case invocation -- much like the setUp() and tearDown() overloads in the xUnit family of frameworks.
The fixtures *are* constructed/destroyed per test case.
Even the global fixture? I was under the impression that the global
No. Global fixtures are constructed/destructor pre post whole testing process.
Right, thanks for making that clear. Thanks again, and hope to see that documentation soon! -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
For now I'll resort to header-reading to find out how to use the macros, though it would be nice to have a one-stop library reference or guide for Boost.Test.
New docs will appear this weekend one way or another. Gennadiy
participants (3)
-
Bruce Trask -
Dean Michael Berris -
Gennadiy Rozental