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
