Even so (suite or not), if a fixture throws from the ctor, the framework should be prepared for that. I tried the following (1.33.1):
--- namespace { struct Fixture { Fixture() { throw std::runtime_error("oops!"); } }; }
BOOST_FIXTURE_TEST_CASE(Failure, Fixture) {} ---
And the output was:
--- unknown location(0): fatal error in "Failure": std::runtime_error: oops! ---
Ideally, I'd like the framework to be able to differentiate between a Fixture construction failure (i.e. xUnit::TestXxx::setUp) and an error originating from e.g. BOOST_CHECK_xxx. Perhaps having a boost::test::setup_failure exception class that one could use for this purpose?
With current design fixture is a natural part of test case. I recommend to use specific exception to report init failures.
struct F{} f;
TEST_CASE( t1 ) { f.i ... }
TEST_CASE( t2 ) { f.i ... }
And could you do this while using suites / fixtures - or is this part of the new functionality?
Why not? You were always able to do this even with explecetly registerred tet cases.
I don't see a need for this. BOOST_AUTO_TEST_SUITE_END ends any test suite.
I understood that (as you can see from my writing above). It's just that there exists BOOST_AUTO_TEST_SUITE and BOOST_AUTO_TEST_SUITE_END (which is symmetric and nice), but then there's also BOOST_FIXTURE_TEST_SUITE and it's not very intuitive to use BOOST_ *AUTO* _TEST_SUITE_END to end that suite.
Perhaps use a plain BOOST_TEST_SUITE_END instead?
I do not want to interfere with BOOST_TEST_SUITE macro that is used for explicit suite creation.
Another question, is there any possibility to implement hierarchical auto test suite registrations, e.g.:
<i/o test suite> - "io" <ip test suite> - "ip" <http test suite> - "http" <file test suite> - "file"
... etc ...
Yes. BOOST_AUTO_TEST_SUITE could be put inside one another. Check examples in libs/example directory.
I've searched, but couldn't find any examples with nested test suites. I only found one example with multiple test suites within the same file. Could you give me a pointer?
unit_test_example_04.cpp should give you introduction into suites usage. Indeed it does not show multilevel hierahy, but I will address this.
Even if this is possible, does the current implementation require the suites to be defined within the same compilation unit? To be able to scale using this approach (I'm talking scaling within the context of maintaining large sets of unit tests), this should not be necessary.
I will need to check this.
With reference to the test runner, it would be great to be able to specify e.g.:
<runner> --run-tests "io" run all tests from "io","ip","http","file" test suites <runner> --run_tests "io/ip" run all tests from "ip","http" test suites
"Run test by name" is scheduled for update 3.
That's great - should that work with nested test suites as in my example above?
Will see. I think so. Gennadiy