Parallel execution of unittests

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Mon May 5 08:40:07 PDT 2014


On 5/5/14, 8:16 AM, Dicebot wrote:
> On Thursday, 1 May 2014 at 19:22:36 UTC, Andrei Alexandrescu wrote:
>> On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
>>> On 2014-05-01 17:15, Andrei Alexandrescu wrote:
>>>
>>>> That's all nice, but I feel we're going gung ho with overengineering
>>>> already. If we give unittests names and then offer people a button
>>>> "parallelize unittests" to push (don't even specify the number of
>>>> threads! let the system figure it out depending on cores), that's a
>>>> good
>>>> step to a better world.
>>>
>>> Sure. But on the other hand, why should D not have a great unit testing
>>> framework built-in.
>>
>> It should. My focus is to get (a) unittest names and (b) parallel
>> testing into the language ASAP.
>>
>> Andrei
>
> It is wrong approach. Proper one is to be able to define any sort of
> test running system in library code while still being 100% compatible
> with naive `dmd -unittest`. We are almost quite there, only step missing
> is transferring attributes to runtime unittest block reflection.

Penalizing unittests that were bad in the first place is pretty 
attractive, but propagating attributes properly is even better. -- Andrei


More information about the Digitalmars-d mailing list