Continuous Integration

[Christopher Wright]

Jason House wrote:
> 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)

Currently DUnit does a lot of work with static constructors, and I'm not 
sure how they interact with unittest blocks.

If DUnit used unittest blocks instead of delegates and static 
constructors, that would be less control, since you'd only get two 
benefits: named tests and continuing testing after one failure. Well, 
three, actually; I could also do some aggregate reports and such, if you 
used a main() that I supplied.

If I add some feature later that lets you specify which tests to run via 
commandline options, those wouldn't be available with a unittest{} 
wrapper. Anything that affects the actual running of the tests and not 
the accounting.

>> 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.

Of course, you can make editor macros to take most of the pain away.