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