Parallel execution of unittests

Xavier Bigand via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 30 18:12:17 PDT 2014


Le 30/04/2014 17:43, Andrei Alexandrescu a écrit :
> 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.
>
I think it's a great idea, mainly for TDD. I had experiment it with 
Java, and when execution time grow TDD loose rapidly his efficiently.
Some Eclipse's plug-ins are able to run them in parallel if I remember 
correctly.

> 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.
>
IMO naming is important for reporting tools (tests status, 
benchmarks,...). Unittests evolves with the rest of the code.

> 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



More information about the Digitalmars-d mailing list