Parallel execution of unittests

[via Digitalmars-d]

On Wednesday, 30 April 2014 at 18:19:34 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> On Wed, 30 Apr 2014 17:58:34 +0000
> Atila Neves via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>> Unit tests though, by definition (and I'm aware there are more 
>> than one) have to be independent. Have to not touch the 
>> filesystem, or the network. Only CPU and RAM.
>
> 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
> 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).
>
> - Jonathan M Davis


On what's a unit test: I +1 everything Dicebot and Russell Winder 
said. Of course there are functions with side effects. Of course 
they should be tested. But those tests aren't unit tests. Which 
won't stop people from using a unit test framework to run them. 
In fact, every test I've ever written using python's unittest 
module was an integration test.

But again, you're right. Whatever changes happen have to take 
into account the current status. And the current status makes it 
difficult if not impossible to run existing tests in multiple 
threads by default. One could argue that the Phobos tests should 
be changed too, but that won't help with the existing client 
codebase out there.