Parallel execution of unittests

[Jacob Carlborg via Digitalmars-d]

On 06/05/14 20:39, Dicebot wrote:
> On Tuesday, 6 May 2014 at 18:28:27 UTC, Jacob Carlborg wrote:
> d.
>> I don't see why would be bad to use "unittest" for integration tests,
>> except for the misguided name. It's perfectly to place "unittest" is
>> completely different modules and packages. They don't need to be
>> placed inline.
>
> Well I am actually guilty of doing exactly that because it allows me to
> merge coverage analysis files :) But it is not optimal situation once
> you consider something like parallel tests as compiler does not know
> which of those blocks are "true" unit tests.
>
> It also makes difficult to define a common "idiomatic" way to organize
> testing of D projects. I'd also love to see a test library that helps
> with defining integration tests structure (named tests grouped by common
> environment requirements doing automatic cleanup upon finishing the
> group/block) without resorting to custom classes AND without interfering
> with simplicity of existing unittests.
>
> I think it all can be done by keeping existing single "unittest" keyword
> but using various annotations. Then integration tests can be done as
> separate application that uses imaginary Phobos integration tests
> library to interpret those annotations and provide more complex test
> structure. And running plain `rdmd -unittest` on actual application
> modules will still continue to do the same good old thing.

So you're saying to use the "unittest" keyword but with a UDA?

Something I already do, but for unit tests. Well my idea for a testing 
framework would work both for unit tests and other, higher levels of test.

@describe("toMsec")
{
     @it("returns the time in milliseconds") unittest
     {
         assert(true);
     }
}

-- 
/Jacob Carlborg