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? There is nothing in the language which has ever mandated that unittest blocks be parallelizable or that they be pure (which is essentially what you're saying all unittest blocks should be). And restricting unittest blocks so that they have to be pure (be it conceptually pure or actually pure) would be a _loss_ of functionality. Sure, let's make it possible to parallelize unittest blocks where appropriate, but I contest that we should start requiring that unittest blocks be pure (which is what a function has to be in order to be pararellized whether it's actually marked as pure or not). That would force us to come up with some other testing mechanism to run those tests when there is no need to do so (and I would argue that there is no compelling reason to do so other than ideology with regards to what is truly a "unit" test). On the whole, I think that unittest blocks work very well as they are. If we want to expand on their features, then great, but let's do so without adding new restrictions to them. - Jonathan M Davis