From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2002-10-08 13:32:45
> Yes we have problems with compilation in many of the cases.
> The failures in
> general aren't so very numerous (or else fall into particular
> that we will end up with too many separate files IMO. Using
> one big file
> (even with the unit test framwork) would be a step backwards
> IMO, we need to
> get finer grained information back to the user so that they know which
> traits may have problems with their compiler.
>From the standpoint of error code you are right - test will fail even if one
test case is failing.
>From the information stand point you will be able to see which test cases
are failing if you request the detail testing report.
> > You did not express an opinion on my proposition on result
> pattern file. I
> > think it will allow you transparently manage expected
> failures without
> > to change the structures of your tests.
> I'm saying that the concept of expected failure is flawed
> (and yes I know I
> put them in there in the first place!), basically using
> expected failures in
> this way is just rigging the the tests so that they succeed.
> It doesn't get
> the information back to the end user IMO.
Note that report pattern file is a bit different from expected failures. It
store the complete results of testing for specific compiler, so you would
know when something changed. In adition it allows you to get a detailed
report how test behave for this (or all) compilers includiong all assertions
that pass and fail. This is the information you would present for end user.
It could be part of regression test procedure.
> We have some things that can fail "safely", and/or which can
> only be made to
> work with the help of compiler extentions: is_POD for
> example. I think Dave
> is right here, these are the only ones where we should
> tolerate failure.
> Perhaps we could use BOOST_MESSAGE and/or BOOST_WARN_MESSAGE here.
Yes, I think that BOOST_WARN_MESSAGE would be the best choice.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk