On Sat, 03 May 2014 19:36:53 -0700 Walter Bright via Digitalmars-d <digitalmars-d@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