[boost] Re: boost.test covered in testing frameworks rundown

From: Noel Llopis (nll_pub_at_[hidden])
Date: 2005-01-10 12:29:52

Gennadiy Rozental wrote:
> Actually Boost.Test doesn't impose that many dependencies (in other 
> case it wouldn't be able to use it for boost internal testing).
> It does depend config subsystem and some other core part of boost (like
> smart_ptr for example), which are mostly targeted for TR1. But namely 
> due to this dependencies (not in spite of) Boost.Test achieve 
> it's portability. 

That's something that in general, I would love to see for every Boost 
library: A list of what other libraries it depends on. Ideally, I'd love to 
see a dependency graph between all the libraries. That way I can use a 
library without the fear of pulling in tons of other libraries (or having 
to wade through tons of headers).

I'm glad to hear that Boost.Test doesn't pull in too many other libraries. 
When I saw the shared_ptr I feared the worst. By the way, why is it using 
shared_ptr? Sure, it's convenient, but wouldn't it be better to minimize 
dependencies completely from other parts of Boost?

> TEST ( MyFixture, TestCase1)
> {
>     BOOST_CHECK_CLOSE ( someValue, 2.0f, 0.005f);
> }
> 
> If you find it generally useful I could add this helper macro into
> framework.

That would be truly excellent! Please go ahead and add it to the framework.

> Boost.Test supply 2 predefined log formats (human readable and XML, which
> you could select by command-line) and unit_test_log_formatter interface
> you could implement for you own formats. What else do you need?

One that we would need right off the bat is the ability to output the log to 
DebugOutputString() when running in Windows doing development in Visual 
Studio. What would be necessary to do that? Write a new unit_test_log?

> Adding test_suites usually means only something like this:
> 
> test_suite* test = BOOST_TEST_SUITE( "Master test suite" );
> 
> test_suite* ct  = BOOST_TEST_SUITE( "Constructors test" );
> test->add( ct );

Right. The problem is that suites will be spread across multiple cpp files. 
So for each suite not only do need to put it together in each cpp file, but 
then I have to go to main.cpp and add it to the master suite.

After looking at it some more, I was able to simplify it further to 
something like this:
test_suite * GetSuite1() 
{
    test_suite * suite  = BOOST_TEST_SUITE("my_test_suite");
    
    boost::shared_ptr<MyTest> instance( new MyTest() );
    suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase1, instance ));
    suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase2, instance ));

    return suite;
}

It still requires me to explicitly call GetSuiteX() from main for every 
suite though, which is unfortunate.

I will look at the method you suggested for making suite registration more 
streamlined.

> Did you really mean that Boost.Test is only PC oriented? Or it's actually
> something different? Like: "If you aren't doing embedded development..."

I meant it from the point of view of game development. If you're not doing 
PC development, you're doing something close to embedded systems 
development (game consoles, handhelds, etc).

Thanks again for the discussion. The more we discuss Boost.Test, the closest 
it's getting to my ideal test framework. Thanks :-)

--Noel