Helper unit testing functions in Phobos (possible std.unittests)
Adam Burton
adz21c at gmail.com
Sat Nov 6 12:45:32 PDT 2010
bearophile wrote:
> spir:
>
>> Jonathan M Davis:
>>
>> > I believe strongly that a unit test block which has a failure should
>> > end excecution. For many such tests, continuing would be utterly
>> > pointless, since each successive test relies on the last.
>>
>> I don't understand. I can have one dozen test cases for each of one dozen
>> funcs. All 144 tests are independant. I prefere the possibility to see
>> all test errors in one go, if any. Anyway, there may be a flag
>> STOP_AT_FIRST_TEST_ERROR (or the opposite).
>
> If you look at all the unittests used in the real world (D is not one of
> them yet), they give you statistics, they tell you how many tests have
> failed. So unittesting goes on when there is an error. A single unittest
> may be stopped if there is a failure inside it. This is how D behaves now,
> and I think it's correct.
>
> Bye,
> bearophile
Depends how you are defining test. Do you mean an individual test on a unit
or tests among multiple units? Personally I prefer to design my tests on a
single unit to all be independant of each other (so any common data and
types are reset at the start of each test). By having multiple tests fail I
can often find the fault common among all of them which usually allows me to
fix an issue faster. If all the tests on the unit depended on each other I'd
only be able to rely on the first test that failed which gives me less
information to go on.
More information about the Digitalmars-d
mailing list