Parallel execution of unittests

[via Digitalmars-d]

On Wednesday, 30 April 2014 at 19:20:20 UTC, Dicebot wrote:
> 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.

I TDD a lot. Tests failing are normal. Not only that, I refactor 
a lot as well. Which causes tests to fail. Fortunately I have 
tests failing to tell me I screwed up.

Even if failing tests were exceptional, I still want everything I 
just mentioned.

>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.
>

And when I split them I put them into a subcategory.