|
Boost : |
Subject: Re: [boost] [Boost.Test] Assertion changes in trunk? [WAS: Call for Review: Boost.Test documentation rewrite]
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-02-14 05:00:59
On Jan 24, 2014, at 5:58 AM, Alexander Lamaison <awl03_at_[hidden]> wrote:
> legalize+jeeves_at_[hidden] (Richard) writes:
>
>> Alexander Lamaison <awl03_at_[hidden]> spake the secret code
>> <868uu8nv96.fsf_at_[hidden]> thusly:
>>
>>> As 'CHECK' is the assertion level you should use by default, [...]
>>
>> I don't know why you would say that when it is contrary to accepted unit testing practices and the behavior of assertions in other testing frameworks in every other language otu there.
>
> Tests cases should test one, and only one, logical concept each. Therefore, multiple assertions in the same tests case will all be testing the same concept. In other words, they are, together, constructing a report of the failure.
>
> Often this is possible using only one assertion, in which case CHECK and REQUIRE are equivalent, but sometimes more than one non-mutually-exlusive assertion is needed to give the full picture.
>
>> For instance, jUnit doesn't continue executing the test past the first failed assertion. Neither do unit testing frameworks in JavaScript or
>> Python or PHP, etc.
>
> Their loss ;)
>
> Seriously though, I find it helps to have multiple bits of data included a single test cases's failure report. It maximises my chances of getting the case to pass next time, which is important in C++ where there is compilation step in between to slow down the test-edit-test loop.
I agree with most of what Alex has said. I have both assert and verify macros in my unit test library. The former aborts the test, via an exception, and the latter sets the failure flag but permits execution to continue. Otherwise, they work exactly alike in terms of reporting output. However, I wouldn't go so far as to say which should be the default macro to use.
___
Rob
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk