Re: [boost] [test] self-registration facilities

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-12-16 10:48:39

> 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