Improving unit tests

[Nick Sabalausky]

"Gide Nwawudu" <gide at btinternet.com> wrote in message 
news:i8k9h49nr5fk5l11qu8ujq5p42ck1kdmbd at 4ax.com...
> On Fri, 07 Nov 2008 16:55:14 -0500, Jason House
> <jason.james.house at gmail.com> wrote:
>
>>Janderson Wrote:
>>
>>>  > Someone who's a big unittesting fan should write up a proposal on
>>>  > this.  I think unittests are neat and all -- I probably don't use 
>>> them
>>>  > as much as I should -- but I don't really know what's so great about
>>>  > named unittests or other things people mention that D's unittests
>>>  > lack.  I suspect Walter may be in the same boat.  You can't address a
>>>  > problem if you don't really understand it.
>>>  > --bb
>>>
>>> Its funny, I was just thinking last night of starting a new thread about
>>> exactly that.  For me I only ever use unit tests in a simple way however
>>> I'd like to learn about move advanced features that D is missing.
>>>
>>> I was originally thinking, maybe unit tests shouldn't be part of D to
>>> allow for innovation. However then I though, what about if D's unit
>>> tests where extensible though some language syntax?
>>>
>>> Questions:
>>> 1) What features are missing from D's unit tests that you miss?
>>
>>Named unit tests
>>Reporting individual failures and continuing. Note that you can recover 
>>from module testing failures, but not from individual tests.
>>Compile-time unit tests, especially when making release builds.
>>
>
> Nestable named unittest would be nice. If one group fails, report the
> error and move onto the next.
>

Last time I tried to use D's unittests, I had a ton of assert statements. On 
the first run one of them triggered, obviously halting execution, and I 
immediately said to myself "this is stupid" and set out writing a 
"NonFatalAssert()" utility function that displayed assertion failures to 
Stdout, incremented a "numFailures" counter (that's later queried at the 
beginning of main(), along with the flushing of Stdout), and continued 
onward.

So yes, I'd say the ability keep the tests going after one failure 
(preferably with descriptive names and grouping) is pretty important.

>>
>>> 2) Should D decouple unittests from the language or should there be
>>> language changes to allow for for more extensible unit tests?
>>
>>I like having them built in.
>
> Agreed
>

Ditto