From: williamkempf_at_[hidden]
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
had
> >a quick comment. The Test tools have been really great for some
of my
> >development work. I can put together some quick executables to
test
> >out functionality, and with the help of gnu automake, I can put
> >together a test suite rather quickly. My one question is in
regard to
> >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
taken
> >care of for me. I was hoping to use the execution tools in
production
> >code, but I find the "no errors detected" message to be about the
only
> >hindrance to this. I'd rather not have my apps output this
message
> >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)
would
> call catch_exceptions many times so shouldn't pester the user with
needless
> messages.
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
the
> 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
see a
> good way to do that at runtime without changing the interface,
which isn't
> desirable. Maybe a compile time macro. BOOST_TEST_SUCCESS_MESSAGE
if you
> 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
desirable
> 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.
Bill Kempf