D For A Web Developer

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Sat May 3 21:34:45 PDT 2014


On Sat, 03 May 2014 19:36:53 -0700
Walter Bright via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
> > I'm not sure mock networks can really be used for testing a
> > client-only lib of some specific protocol. There may also be other
> > examples.
> >
> > There's also the question of whether or not D's "unittest {...}"
> > should *expect* to be limited to tests that are *technically* "unit
> > tests". Currently, "unittest {...}" is useful for more forms of
> > testing than just "unit" tests. I think it's debatable whether we
> > want kill off those uses without offering a comparable alternative
> > with reasonable migration.
>
> I'm not suggesting killing off anything. I'm suggesting it may not be
> good practice to use unit tests for testing actual networks.

I'd write unit tests which talked to sockets on the same computer if that
was what was required to test a particular function, but I would definitely
consider it bad practice to have a unit test try to talk to anything on a
separate computer. Now, if you're using unittest blocks for something other
than unit tests, then I guess that that could be fine, though I question that
it's good practice to use unittest blocks for other purposes.

Regardless, unittest blocks don't really put any restrictions on what kind of
code can go in them, and I'd prefer that that stay the case. The discussion
on parallelizing unit tests threatens that on some level, but as long as we
have the means to mark unittest blocks in some manner that tells the test
runner not to run them in parallel with any other unittest blocks, then I
think that we should be fine on that front.

- Jonathan M Davis


More information about the Digitalmars-d mailing list