"Matt Schuckmann" wrote in message news:44B6DA44.8020305@schuckmannacres.com...

I've been looking into using the boost test library to start testing some of our code and it looks pretty good. I've gone through the documentation and several of the examples and there are a couple of things I don't really get

So I gather you are using boost 1.33.1, right?

I don't see how the test_suite class lets you create do anything special with regards to building multi-level tests, none of the examples really show multilevel test hierarchy and how it really helps me.

There is a unit_test_example3 that builds multilevel hierarhy.

It looks like it's really just a way of using a class to group test functions instead of a series of free functions, am I missing something here?

test_suite is subclass of test_case. You could use method "add" to build hierahies.

I really expected more from a feature like this, I'm thinking of things like Command line control over which test suites to run, I mean you name the test suites but you don't appear to do anything with that name

Run by name is planned to be implemented in 1.35

Reporting success and failure grouped by test suite

You could use --report_level=detailed for that

Am I missing something here, is this stuff possible and the examples don't show it or are these feature that are yet to come or haven't been thought of?

I don't see a good example for how I should setup a unit test for a real world type project you know an extensive example that covers inputs, outputs, multiple test suites, etc all in one example.

Take a look how Boost.Test internal test are build. I personally rarely used multilevel hierarhies, but that minor feature IMO unless you are into hardcore TDD..

In my case I've a got a library with several independent classes and functions that I'd like to test and I'm not sure if I should be creating multiple executables (1 for each test case) or a single executable that tests everything, I don't understand the pros and cons of either case. It seems like I want the single executable that can test everything or that can test just want I tell it to test.

It's really up to you. There several guidelines on how to split your unit tests by test modules, but iun the end it just your preference: * each program unit (possible single class or several cooperating) has separate test module * performace test goes in separate module * feature that may cuase compile time failure should go in separate module * Each feature goes in separate test case: construction/destruction/access methods/printing etc

Any info would be appreciated.

Also I really recomment consider using auto registration facilities, especially if you could use latest cvs version of Boost.Test.

Matt S.

Gennadiy