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