lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Relaxing BOOST_TEST_THROW() message test to do substring match


From: Greg Chicares
Subject: Re: [lmi] Relaxing BOOST_TEST_THROW() message test to do substring match only
Date: Thu, 18 Feb 2016 02:26:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 2016-02-18 01:37, Vadim Zeitlin wrote:
> 
>  I'd like to propose relaxing the test of the message carried by the
> expected exception in BOOST_TEST_THROW() to check that it appears in the
> effectively thrown exception as a substring, instead of being exactly equal
> to it.
> 
>  The reason for this proposal is that currently it's difficult and error
> prone to exactly match the exception message, especially when it contains
> some dynamic information (e.g. the line number and possibly the column in
> the exceptions thrown by the code reading SOA files). Moreover, once you
> manage to do it, you need to keep remembering to update the tests if the
> exception message changes, even if very slightly.

That suits my personal habits, but I appreciate your objection to it.

>  IMO checking for substring, instead of exact, match, would be a better
> solution because it wouldn't really weaken the existing tests and would
> make using "" much less appealing thus strengthening the future ones. And
> as a nice side effect, this would also make the macro implementation
> simpler as it wouldn't need to worry about "\n[file" part.
> 
>  What do you think?

Could we make this optional? Then I can have the rigid tests I like,
and you can have greater flexibility. And who knows, I might someday
come round to your point of view. But I'm opposed to relaxing tests
that have proved valuable without reviewing each one carefully, yet
I can't make time for such review.

Is there some tidy way to implement both approaches in parallel?

Now that we have <regex> in libstdc++, would you want to test regexen
instead of substring matches? E.g.: /failure on line [0-9]+/ if the
exact line is irrelevant or somehow indeterminate?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]