[dmd-internals] changeset 455

Andrei Alexandrescu andrei at erdani.com
Mon May 3 16:11:04 PDT 2010


Walter Bright wrote:
> 
> 
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>>
>>>
>>> Andrei Alexandrescu wrote:
>>>> Since we've been looking into this now and we have a solution in our 
>>>> collective mental caches, is there please a chance to effect this 
>>>> change for this beta? I'm telling you, it is an _important_ step 
>>>> forward in unittesting D programs.
>>>>
>>>
>>> One thing I should mention is that dmd now calls a different function 
>>> for unittest asserts than the asserts normally do, and it does not 
>>> regard those calls as "terminating" calls. This means that the 
>>> unittest behavior can now be controlled by adjusting the runtime 
>>> library, without affecting the assert failure code.
>>
>> In light of Sean's latest discovery, I'm afraid there's an issue here. 
>> The asserts are only replaced syntactically at top-level unittests. My 
>> understanding was that there was a "unittest stage" global that 
>> dictates how assertion failures are handled, regardless of origin.
>>
>> I'm unclear on what the best policy is. Experience suggests that flat 
>> == bad.
>>
> 
> I'm reluctant to transform all asserts because:
> 
> 1. this means all asserts, whether meant for unit testing or not, have 
> to have return code, negatively affecting optimization all the time

This sounds like latching onto an implementation artifact. The way I'm 
seeing things is:

bool g_runningUnittests;

// C entry point
int _main() {
     g_runningUnittests = true;
     __runUnittests();
     g_runningUnittests = false;
     d_main();
}

The implementation of assertFailed() consults g_runningUnittests. And 
that's all there is to it.

> 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.


Andrei


More information about the dmd-internals mailing list