|
Boost : |
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-07-23 15:45:02
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk