std.experimental.testing formal review

[Atila Neves via Digitalmars-d]

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