[phobos] Silent failure of std.container unittests

[Benjamin Shropshire]

Walter Bright wrote:
>
>
> Adam Ruppe wrote:
>> On 7/15/10, Walter Bright <walter at digitalmars.com> wrote:
>>  
>>>> Assertion failure should abort the current unittest block.
>>>>
>>>> Do we all agree about the above?
>>>>       
>>> Not me.
>>>     
>>
>> That's madness!
>>
>> unittest {
>>     auto a = something();
>>     assert(a !is null);
>>      a.stuff(); // if a is null, this is meaningless
>> }
>>   
>
> Yes, and I could easily rewrite that as:
>
> unittest {
>    auto a = something();
>    if (a)
>        a.stuff();
>    else
>        assert(0);
>
> Is that worse than your rewrite of the following?
>
>>  
>>> Everybody's happy except the guys like me who want to run all the unit
>>> tests in one go.
>>>     
>>
>> What you could do is:
>>
>> unittest { assert(my test); }
>> unittest { assert(my other test); }
>> unittest {
>>   // complex test
>> }
>>
>> It is a bit verbose, but you'd get all the results you want without
>> breaking cases like my first null assert one.
>>
>>   
>
> Yeah, but try it if you want to go through a table of inputs and 
> compare the results to a table of outputs. Of course, that can be 
> done, too, but it's extra code as well.

Can we all agree that  a failed assert should end a "Unit test" ("Unit 
test" != unittest)?

My thought is, that we might be running into issues because the idea of 
a unit test is being conflated with a function. What we really want is a 
collection of blocks of code that that are all run and if any of them 
trigger an assert, that block stops and the tests as a whole are 
considered to have failed.

As a point to start from, how about allow unittest as a statement type?

foreach(item; collection) unittest { asssert(foobar(item)); }

> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>