Parallel execution of unittests

[Atila Neves via Digitalmars-d]

On Wednesday, 30 April 2014 at 16:24:16 UTC, QAston wrote:
> On Wednesday, 30 April 2014 at 15:43:35 UTC, Andrei 
> Alexandrescu wrote:
>> Hello,
>>
>>
>> A coworker mentioned the idea that unittests could be run in 
>> parallel (using e.g. a thread pool). I've rigged things to run 
>> in parallel unittests across modules, and that works well. 
>> However, this is too coarse-grained - it would be great if 
>> each unittest could be pooled across the thread pool. That's 
>> more difficult to implement.
>>
>> This brings up the issue of naming unittests. It's becoming 
>> increasingly obvious that anonymous unittests don't quite 
>> scale - coworkers are increasingly talking about "the unittest 
>> at line 2035 is failing" and such. With unittests executing in 
>> multiple threads and issuing e.g. logging output, this is only 
>> likely to become more exacerbated. We've resisted named 
>> unittests but I think there's enough evidence to make the 
>> change.
>>
>> Last but not least, virtually nobody I know runs unittests and 
>> then main. This is quickly becoming an idiom:
>>
>> version(unittest) void main() {}
>> else void main()
>> {
>>   ...
>> }
>>
>> I think it's time to change that. We could do it the 
>> non-backward-compatible way by redefining -unittest to 
>> instruct the compiler to not run main. Or we could define 
>> another flag such as -unittest-only and then deprecate the 
>> existing one.
>>
>> Thoughts? Would anyone want to work on such stuff?
>>
>>
>> Andrei
>
> An existing library implementation:
> https://github.com/atilaneves/unit-threaded

Beat me to it! :P

The concurrency and naming aspects are exactly what drove me to 
write unit-threaded to begin with. I probably wouldn't have 
bothered if D already had the functionality I wanted.

Atila