Does anyone have a setup for doing continuous integration with d?

Jason House wrote:
> Does anyone have a setup for doing continuous integration with d?

I'm going to start on that now, since DUnit (latest svn) can output vaguely junit-compatible xml. It'll be using CruiseControl. By tomorrow, I'll be able to tell you when you should start bothering me about it in earnest.

Of course, this will do you little good if you don't use DUnit or some other unittest runner besides the default one, since you just get a binary value for whether your tests pass, along with, if you're lucky, a stack trace. If you're not lucky, you just get the words "Segmentation fault".

Well, okay, you could have a static constructor that outputs the first portion of the junit xml file, a couple of templates and functions that output more xml for each unittest, and your unittest main would output the end of the junit xml, or something like that. But at that point, you might as well just use DUnit.

Christopher Wright Wrote:

> Jason House wrote:
> > Does anyone have a setup for doing continuous integration with d?
> 
> I'm going to start on that now, since DUnit (latest svn) can output vaguely junit-compatible xml. It'll be using CruiseControl. By tomorrow, I'll be able to tell you when you should start bothering me about it in earnest.
> 
> Of course, this will do you little good if you don't use DUnit or some other unittest runner besides the default one, since you just get a binary value for whether your tests pass, along with, if you're lucky, a stack trace. If you're not lucky, you just get the words "Segmentation fault".
> 
> Well, okay, you could have a static constructor that outputs the first portion of the junit xml file, a couple of templates and functions that output more xml for each unittest, and your unittest main would output the end of the junit xml, or something like that. But at that point, you might as well just use DUnit.

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.

Christopher Wright wrote:
> Jason House wrote:
>> Does anyone have a setup for doing continuous integration with d?
> 
> I'm going to start on that now, since DUnit (latest svn) can output vaguely junit-compatible xml. It'll be using CruiseControl. By tomorrow, I'll be able to tell you when you should start bothering me about it in earnest.

Okay, assuming you are using dsss, you can simply use:

<schedule interval="60">
    <exec workingdir="projects/${project.name}" command="/usr/local/bin/dsss" args="build" timeout="5000" />
</schedule>

If you have a binary that includes your tests, you can change that to:

<schedule interval="60">
    <composite>
        <exec workingdir="projects/${project.name}" command="/usr/local/bin/dsss" args="build" timeout="5000" />
        <exec workingdir="projects/${project.name}" command="./binary" args="some-args" />
    </composite>
</schedule>

If you don't use <composite>, well, that's entirely allowed, but only the first element will be executed.

I don't have xml output for dunit working correctly with cruisecontrol yet.

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.

Jason House Wrote:

> Does anyone have a setup for doing continuous integration with d?

Jason,

You might check out our Parabuild. It is free for open source development. And it will run any build or test that you can run from the command line.

Sergey Pashin

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
  });
}


My limit is probably something near:

unittest{
  mixin startTest!("My test name");
  try{
    ... // my code
  catch{
    mixin catchTest;
  }
}


I'd like to stay with the D style of unit tests.  Maybe I should check what enhancement requests are in there.  It'd be nice to be able to hook in a unit test handler...

== Quote from Jason House (jason.james.house@gmail.com)'s article
> I'd like to stay with the D style of unit tests.  Maybe I should check what enhancement requests are in there.  It'd be nice to be able to hook in a unit test handler...

Tango has one.  Look at "moduleUnitTester" here:

http://www.dsource.org/projects/tango/docs/current/tango.core.Runtime.html


Sean

Sean Kelly wrote:

> == Quote from Jason House (jason.james.house@gmail.com)'s article
>> I'd like to stay with the D style of unit tests.  Maybe I should check
>> what
>> enhancement requests are in there.  It'd be nice to be able to hook in a
>> unit test handler...
> 
> Tango has one.  Look at "moduleUnitTester" here:
> 
> http://www.dsource.org/projects/tango/docs/current/tango.core.Runtime.html
> 
> 
> Sean

See http://d.puremagic.com/issues/show_bug.cgi?id=1952 for the enhancement request.  Per unit test customization (such as a unit test name) is very useful to have.  I also don't see a way to tell the program to run all unit tests (and just report the individual passes/failures)

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

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