On Tuesday, 15 September 2015 at 08:27:29 UTC, Dicebot wrote:
On Sunday, 13 September 2015 at 10:44:30 UTC, Atila Neves wrote:
2) being able to do weak ordering of tests (by defining
strict sequence of groups so that
parallelization/randomization only happens within such group)
- I have used something as simple as numerical priority value
so far for my needs
There's `@singleThreaded` for that: all tests in a module with
that UDA run in series (other modules are still run in
parallel). I didn't think one was needed for random ordering.
Atila
I had inverse thing in mind - all tests within a module / block
run in parallel, but blocks run sequentially. It is not a good
feature for unit tests but quite important one to higher level
ones which deal with nasty environment issues.
I'm not sure we're understanding each other. With the current
implementation and a module like this:
@singleThreaded
@name("serial1") unittest { ... }
@singleThreaded
@name("serial2") unittest { ... }
@name("parallel1") unittest {... }
@name("parallel2") unittest { ...}
3 tasks would get scheduled in parallel: parallel1, parallel2,
and a composite task that does serial1 then serial2. If there are
any other modules, all of the other tests run in parallel with
these 3 tasks.
I'm proposing to extend the same behaviour to randomised running
of tests, but if that's the case the name would change.
Atila
