[dmd-internals] changeset 455

[Denis]

On Tue, May 4, 2010 at 3:11 AM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> 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
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

What's wrong with automatically wrapping unittests with try/catch
block? Why is the "bool g_runningUnittests;" even necessary?
Anyway, I believe top-level unittest assert behavior shouldn't differ
from other asserts.