Parallel execution of unittests

[Xavier Bigand via Digitalmars-d]

Le 30/04/2014 22:09, Russel Winder via Digitalmars-d a écrit :
> On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via Digitalmars-d
> wrote:
> […]
>> I disagree with this. A unit test is a test that tests a single piece
>> of functionality - generally a function - and there are functions which
>> have to access the file system or network. And those tests are done in
>
> These are integration/system tests not unit tests. For unit tests
> network activity should be mocked out.
>
And how you do when your mock is bugged? Or you risk to have the mock up 
to date when changing the code but not the running application cause 
before the commit you'll run only your unittests.
IMO every tests can be automatize and run in a few time have to be run 
before each commit even if some are integration tests.

>> unittest blocks just like any other unit test. I would very much
>> consider std.file's tests to be unit tests. But even if you don't
>> want to call them unit tests, because they access the file system, the
>> reality of the matter is that tests like them are going to be run in
>> unittest blocks, and we have to take that into account when we decide
>> how we want unittest blocks to be run (e.g. whether they're
>> parallelizable or not).
>
> In which case D is wrong to allow them in the unittest blocks and should
> introduce a new way of handling these tests. And even then all tests can
> and should be parallelized. If they cannot be then there is an
> inappropriate dependency.
>