Re: [Boost-users] [unit_test_framework] checkpoints for BOOST_CHECK*?

Subject: Re: [Boost-users] [unit_test_framework] checkpoints for BOOST_CHECK*?
From: rozelak_at_[hidden]
Date: 2009-09-01 15:42:29

> <rozelak <at> volny.cz> writes:
> > There are extensive tests started automatically on
> > regular basis required, and some random permutations
> > are used in some of the special tests (we
> > can discuss about meaningfulness of it, but it is
> > the requirement ...).
> > So, when BOOST_TEST_MESSAGE is used, it either prints
> > everything or nothing (depending on the log level
> > set). It is much more convenient to have only failures
> > included in test results (as boost already does
> > it now, and even I don't care about conditions not
> > resulting in test failure ...). However, I need to
> > have detailed test conditions included within the
> > failure message as well (and they may be quite complex).
> > That's my motivation.
> 
> If these are automated tests:
> 
> 1. Why do you care about content of the output at all.
> I mean just use log_level=message and store all the logs.
> You'll review them if any failures will actually happen.

Yes. But imagine that dozens of lines are printed (or stored
into a log)and you have to look through all the messages. OK,
it is not a big problem, it is rather uncomfortable. I believe
that having the possibility of printing user-defined messages
on test failures will even increase the comfort of boost-test
framework usage, with no high cost to pay to implement this.
And actually, it is already possible with BOOST_CHECK_MESSAGE.

> 2. You can use XML format and present it to your screen
> in a way you prefer. For example you'll skip messages if test
> case has no failures and show them if it is.

Right again. But it will not work when the test suite is started
from command line where it is more convenient to use simple format
(see 1.).

Bu may I have a question as well? Why do you refuse the extension
of BOOST_WARN|CHECK|REQUIRE_* macro by user-defined massage? It
seems to me as a natural extension of the macros (it is already
possible with BOOST_CHECK_MESSAGE), while it by no means affects
the existing interface. Is it so difficult to implement it? Is
there a general resistance against interface extension?

I am really sorry, but can't see a reason why not to simplify into
one command doing itself effectively what you suggest to workaround
(by the setting of log level, XML filtering, etc?). I offer my try
to code it and send a patch for revision to you, if someone could
provide slight guidance to me.

Thank you very much. Best regards,
Dan.