On 01/05/2014 08:18, Dicebot wrote:
On Wednesday, 30 April 2014 at 21:49:06 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via Digitalmars-d
wrote:
> 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.
Why? Because Andrei suddenly proposed that we parallelize unittest
blocks? If I want to test a function, I'm going to put a unittest block
after it to test it. If that means accessing I/O, then it means
accessing I/O. If that means messing with mutable, global variables,
then that means messing with mutable, global variables. Why should I
have to put the tests elsewhere or make is that they don't run whenthe
-unttest flag is used just because they don't fall under your definition
of "unit" test?
You do this because unit tests must be fast. You do this because unit
tests must be naively parallel. You do this because unit tests verify
basic application / library sanity and expected to be quickly run after
every build in deterministic way (contrary to full test suite which can
take hours).
See http://forum.dlang.org/post/lkb0jm$vp8$1...@digitalmars.com.
(basically, do we want to support only Unit tests, or Integration tests
also?)
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
