On May 2, 2010, at 1:23 PM, 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.
I think the current behavior is a good first step, but should probably be
modified a bit further. For example:
void fnA()
{
assert( false, "fnA 1" );
assert( false, "fnA 2 ");
}
unittest
{
assert( false, "unittest 1" );
assert( false, "unittest 2" );
fnA();
}
unittest
{
assert( false, "unittest 3" );
}
void main()
{
}
Running this will print:
test.d(9): unittest 1
test.d(10): unittest 2
[email protected](3): fnA 1
So if an assert error occurs inside some code being tested, the app will still
exit. I tried modifying the unit testing code to eat the exception and
continue, but then it simply prints:
test.d(9): unittest 1
test.d(10): unittest 2
So the best we can currently do is move on to test another module--there's no
way to execute the remaining unit tests within the module. Could we perhaps
have an array of unittests within the ModuleInfo struct instead of just a
single function pointer? Or is the rationale really that if implementation
code throws, the app should assume it's in an invalid state and exit?
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
