Date: 2001-03-16 14:09:17
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 12:14 PM 3/16/2001, Ronald Garcia wrote:
> >I've been using Boost.Test a bit for some work lately, and I just
> >a quick comment. The Test tools have been really great for some
> >development work. I can put together some quick executables to
> >out functionality, and with the help of gnu automake, I can put
> >together a test suite rather quickly. My one question is in
> >the Execution tools.
> >I definitely like the feel of the execution tools. In the past my
> >main functions have generally been wrapped in a sub-sufficient try
> >block to catch exceptions, but with a switch to cppmain, this is
> >care of for me. I was hoping to use the execution tools in
> >code, but I find the "no errors detected" message to be about the
> >hindrance to this. I'd rather not have my apps output this
> >under normal operation.
> Interesting point. I can see why some would prefer not to see this
> message. And unit test tools (for which we still need a volunteer)
> call catch_exceptions many times so shouldn't pester the user with
Another thing I noticed while using it in Boost.Threads is that you
can't control *where* the messages go. This is acceptable for the
limited command line testing that we're doing now, but it would be
nice to be able to specify different streams for this. This would
allow, for instance, a GUI to display the results in a window.
> > Could this message be factored down to the
> >Test tools level (test_main) such that no errors leads to a silent
> >exit from cpp_main?
> There are cases were cpp_main users like this message. They want
> positive confirmation that the program succeeded. So moving it to
> test_main wouldn't serve those folks well.
> Seems like we need a way to configure the message. I don't offhand
> good way to do that at runtime without changing the interface,
> desirable. Maybe a compile time macro. BOOST_TEST_SUCCESS_MESSAGE
> want the message. What would you think of that?
If we changed the interface to allow the user to specify a stream for
output this could be accomplished with out effecting existing code.
This facility would allow GUI programmers to send the output to a
stringstream or some sort of guistream and for the case of production
code that shouldn't display this information it can be sent to a
fstream or nullstream.
> There is another related issue. The output message to cerr isn't
> when cerr and cout are going to the same place.
Being able to specify the stream would work here as well.
In case it's not clear how to do this "with out effecting existing
code"... you have a set_test_stream() method that sets a "global"
pointer which is then used instead of cerr in the macros. There's
some implementation details that would have to be addressed with this
idea, but it should work.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk