Continuous Integration

[Jason House]

Christopher Wright wrote:

> Jason House wrote:
>> Christopher Wright wrote:
>> 
>>> Jason House wrote:
>>>> I'm sensitive to per-unittest code-writing overhead, but already have
>>>> some in my code. If DUnit offers comparable overhead, and enhanced
>>>> functionality, I'll switch.
>>> DUnit uses test fixture classes, so it probably won't suit you at
>>> present. I'll look into a method with less overhead.
>> 
>> Hmmm... maybe :(
>> 
>> Would this be possible?
>> 
>> unittest{
>>   mixin DUnitTest!("My test name",
>>   {
>>     ...// my code
>>   });
>> }
> 
> Yes. 


Cool :)


> I initially had some issues with alias parameters and delegates, 
> but those seem to have disappeared. You wouldn't want to put that in a
> unittest block, though, since it's redundant and would give me, and by
> extension you, less control.

Huh?  Can you explain?  Would I have less control than DUnit currently
provides or less control thant just a hand made unittest{...}?  In either
case, how severe of a gap are you envisioning?  (So far, D unittest blocks
are my only real unit testing experience.  Work will eventually have me
using NUnit, but that hasn't happened yet)


> You'd also need to either version out your main function or call
> dunit_main from yours when running tests.

I'm totally ok with that!  One-time overhead at a program level isn't too
bad.  Most programs that really use unit tests are moderate or large in
size anyway.  It's the per-test overhead that would really irk me as I code
away.