Parallel execution of unittests
Atila Neves via Digitalmars-d
digitalmars-d at puremagic.com
Fri May 2 03:23:03 PDT 2014
On Thursday, 1 May 2014 at 18:38:15 UTC, w0rp wrote:
> On Thursday, 1 May 2014 at 17:04:53 UTC, Xavier Bigand wrote:
>> Le 01/05/2014 16:01, Atila Neves a écrit :
>>> On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
>>>> On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg
>>>> wrote:
>>>>> On 2014-04-30 23:35, Andrei Alexandrescu wrote:
>>>>>
>>>>>> Agreed. I think we should look into parallelizing all
>>>>>> unittests. --
>>>>>> Andrei
>>>>>
>>>>> I recommend running the tests in random order as well.
>>>>
>>>> This is a bad idea. Tests could fail only some of the time.
>>>> Even if
>>>> bugs are missed, I would prefer it if tests did exactly the
>>>> same thing
>>>> every time.
>>>
>>> They _should_ do exactly the same thing every time. Which is
>>> why running
>>> in threads or at random is a great way to enforce that.
>>>
>>> Atila
>> +1
>
> Tests shouldn't be run in a random order all of the time,
> perhaps once in a while, manually. Having continuous
> integration randomly report build failures is crap. Either you
> should always see a build failure, or you shouldn't see it. You
> can only test things which are deterministic, at least as far
> as what you observe. Running tests in a random order should be
> something you do manually, only when you have some ability to
> figure out why the tests just failed.
In my experience when a test fails randomly because of ordering,
a while loop on the shell running until failure is enough to
reproduce it in a few seconds. But as others have mentioned,
being able to use a seed to reproduce it exactly is superior.
Atila
More information about the Digitalmars-d
mailing list