Peter, Thanks for the reply. I am familiar with the REQUIRE family of checks. However, that kills everything at the lowest level immediately. I have a more subtle problem. Here's an example: For a class being tested, I have a test case to validate the constructor. There are many individual checks in that test case. Just because some individual checks might fail is not a reason to abort the entire constructor test. So, I used CHECKs rather than REQUIRE. Continuing on, there are a number of other test cases for other functionality in the class. However, if the constructor can't be trusted, I could end up with a wild set of "errors" reported in the later test cases. If functionality A is needed by B, B is needed by C, C is needed by D, and so on. Then a logical testing sequence is A, B, C, D. If there is no guaranteed testing order, then, say, the test for D would have to do at least a cursory re-check of A, B, and C so that D would know it's checking what it thinks it's checking. I used Boost Test once before ~5 years ago. It only had manual registration of test cases and test suites (as I remember). That would have provided the ordering I need. However, the auto registration feature of the new version is so much more convenient, I was hoping to use it. The REQUIRE functionality is sort of "one strike and everyone is out." If there is an ordering, then you can start reading the log from the top down. If you really do find something fatal, then you would know to ignore the rest of the test output. Otherwise, all of the other test output can give useful information. I'm guessing that I will have to revert to manual registration. Merrill Cornish