Parallel execution of unittests

[Dicebot via Digitalmars-d]

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.