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.
