Hi Gennadiy, When I use macros such as BOOST_CHECK_MESSAGE( !evidence, "update evidence = " << withEvidenceUpdate << ", evidence = " << *evidence ); it annoys me that the second argument is evaluated even when the test should pass. In the case above, evidence is an optional<int>. It would be cool if the construction of the error messsage could be delayed until it was actually needed, to make the above scenario valid. Do you think that is possible? Thanks -Thorsten
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:461CF01A.4010209@dezide.com...
Hi Gennadiy,
When I use macros such as
BOOST_CHECK_MESSAGE( !evidence, "update evidence = " << withEvidenceUpdate << ", evidence = " << *evidence );
it annoys me that the second argument is evaluated even when the test should pass.
In the case above, evidence is an optional<int>. It would be cool if the construction of the error messsage could be delayed until it was actually needed, to make the above scenario valid.
Do you think that is possible?
The problem is that I might need the message even if test passes(to print confirmation massages, if log level is set to "all"). Why exactly does it bother you? You could always workaround it with your own macro: #define MY_CHECK_MSG( expr, MSG ) \ if( (expr) ) \ {} \ else \ BOOST_CHECK_MSG( false, MSG ) \ /**/ Gennadiy
Gennadiy Rozental skrev:
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:461CF01A.4010209@dezide.com...
Hi Gennadiy,
When I use macros such as
BOOST_CHECK_MESSAGE( !evidence, "update evidence = " << withEvidenceUpdate << ", evidence = " << *evidence );
it annoys me that the second argument is evaluated even when the test should pass.
In the case above, evidence is an optional<int>. It would be cool if the construction of the error messsage could be delayed until it was actually needed, to make the above scenario valid.
Do you think that is possible?
The problem is that I might need the message even if test passes(to print confirmation massages, if log level is set to "all").
I see.
Why exactly does it bother you?
Because my test crashes :-)
You could always workaround it with your own macro:
#define MY_CHECK_MSG( expr, MSG ) \ if( (expr) ) \ {} \ else \ BOOST_CHECK_MSG( false, MSG ) \ /**/
I could do that, but I prefer the library to handle such situations. Is it not possible to generate the message only when it is needed. For example, I don't use log level "all". -Thorsten
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:461E1311.3020101@dezide.com...
Gennadiy Rozental skrev:
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:461CF01A.4010209@dezide.com...
Hi Gennadiy,
When I use macros such as
BOOST_CHECK_MESSAGE( !evidence, "update evidence = " << withEvidenceUpdate << ", evidence = " << *evidence );
it annoys me that the second argument is evaluated even when the test should pass.
In the case above, evidence is an optional<int>. It would be cool if the construction of the error messsage could be delayed until it was actually needed, to make the above scenario valid.
Do you think that is possible?
The problem is that I might need the message even if test passes(to print confirmation massages, if log level is set to "all").
I see.
Why exactly does it bother you?
Because my test crashes :-)
Did it crash within Boost.Test code?
You could always workaround it with your own macro:
#define MY_CHECK_MSG( expr, MSG ) \ if( (expr) ) \ {} \ else \ BOOST_CHECK_MSG( false, MSG ) \ /**/
I could do that, but I prefer the library to handle such situations.
Is it not possible to generate the message only when it is needed. For example, I don't use log level "all".
I will significantly complicate Test Tools macros. We will have to have the code in every assertion location that checks for log levels (that's besides the fact the decision on log entry inclusion/exclusion is currently encapsulated within unit test log component and is not accessible outside). Also test tools vararg impl function expects some arguments to be passed. All in all I'd prefer at this point not to compromise test tools design and implementation without well based issue report that doesn't have a different workaround. Gennadiy
participants (2)
-
Gennadiy Rozental -
Thorsten Ottosen