Parallel execution of unittests

[Dicebot via Digitalmars-d]

On Wednesday, 30 April 2014 at 18:04:43 UTC, Atila Neves wrote:
> On Wednesday, 30 April 2014 at 17:30:30 UTC, Dicebot wrote:
>> I believe only missing step right now is propagation of UDA's 
>> to RTInfo when demanded. Everything else can be done as Phobos 
>> solution.
>>
>> And if requirement to have all modules transitively accessible 
>> from root one is acceptable it can be already done with 
>> http://dlang.org/traits.html#getUnitTests
>>
>> Simplicity of D unit tests is their best feature.
>
> IMHO this best feature is only useful when writing a small 
> script-like program. The hassle of using anything more 
> heavy-duty is likely to make one not want to write tests. The 
> unittest blocks are simple, and that's good.
>
> But for me I wouldn't (and haven't) use them for "real work". 
> When tests pass, it doesn't really matter if they were written 
> with only using assert or what the output was like or any of 
> those things. But when they fail, I want to:
>
> . Run the failing test(s) in isolation, selecting them on the 
> command-line by name
> . Have tests grouped in categories (I use packages) to run 
> similar tests together
> . Be able to enable debug output that is normally supressed
> . Know the name of the test to know which one is failing
> . Have meaningful output from the failure without having to 
> construct said meaningful output myself (assertEquals vs assert)
>
> I don't know about anyone else, but I make my tests fail a lot.

I think this is key difference. For me failing unit test is 
always exceptional situation. And if test group is complex enough 
to require categorization then either my code is not procedural 
enough or module is just too big and needs to be split.

There are of course always some tests with complicated 
environment and/or I/O. But those are never unit tests and thus 
part of completely different framework.