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