Well, that's why I use a Perl script. If you turn the various output levels up high enough, you get (at the end of the test suite output) a unit-test by unit-test summary of each test, how many assertions passed, how many failed, and how many were expected to fail; that's what I use Perl to chop up.
I think XML output would be easier to "chop up", especially if you could employ existing XML parser
One the one hand, I'm wondering if it wouldn't be possible to arrange for the test suite to supply the user with all this info via some API - say, a map of test names to test result structures, or some such - at which point you could arrange the output to look like whatever you want, all within the unit test suite.
You do have an ability ot write custom log and report formatters.
On the other hand, for some unit tests it's hard to avoid having various things output to the console. For example, I've got some unit tests that test our error handling code, including the bit that dumps messages to stderr and quits.
I recomment using output_test_stream for testing output operations
Unless I build into our error handling code some way to redirect these error messages (and I don't really want to do this), this stuff is going to end up in the unit test's output, and I don't see any way around that. Thus, my current thinking: the output from running the unit test suite is A) saved and compared with 'canonical' output,
Again output_test_stream have a nabiltiy ot match to the pattern file.
and B) parsed for the information I want.
I'm sure there's a way to get into the library code and get control of what it does on a lower level. If there isn't, Gennadiy can probably arrange for there to be. :-)
I think you already have almost everything you need. The rest (configuration file support for example) is comming Gennadiy