[dmd-internals] changeset 455

[Andrei Alexandrescu]

Sean Kelly wrote:
> On May 3, 2010, at 4:11 PM, Andrei Alexandrescu wrote:
>>> 2. many asserts are not meant at all to be unit tests, and there's no reason to think otherwise when they are outside the unittest block
>> I guess but I have the feeling you are taking a couple of wrong turns that reflect lack of experience with unittests.
>>
>> 1. A failing unittest only prints and continues
>>
>> 2. Top-level asserts are different from other asserts
>>
>> I'm not claiming to be an expert in unittesting but from what I know from other unittest facilities, I believe the following is the correct behavior:
>>
>> 1. A failing unittest means that particular unittest is terminated immediately and counted as "failed" exactly once. A failed unittest has an identity, you can't say "this unittest has failed 3 times in the following places".
>>
>> 2. unittest-level assert and any-level assert are the same deal. It's basic (de)composability and what anyone expects since the invention of the stack.
>>
>> Please let's not introduce odd behavior unless we're based on something.
> 
> I'm unsure about the current behavior with asserts.  On the one hand I agree with you, on the other I see the unittest-level asserts as a way of reporting a case failure, so it may be reasonable to just continue.  However, perhaps "assert" isn't the best candidate for both operations.

That makes the definition of assert() dependent of lexical context. 
That's not impossible and not unjustifiable - it's just weird without 
good reason.

assert() is assert() is assert(). Why complicate things without reason?

Unittest frameworks have invented a wonderful mechanism for defining 
assertions that behave differently from one another: assigning different 
names for them.

assert(expr); // terminates current unittest
expect(expr); // outputs to stderr if failed, continue unittest

Walter, please: go with the established ways. Don't invent stuff just 
because you can.


Andrei