CURL Wrapper: Congratulations Next up: std.serialize

[Jonathan M Davis]

On Friday, December 30, 2011 13:41:37 Tobias Pankrath wrote:
> When I first came to D, I read "unittest support" and thought that would
> be nice. But after I tried it, I realized it sucks and wrote something
> similar to Jacobs unittest framework.
> 
> > I'm against it. I think that the compiler/runtime should be fixed so
> > that
> > each unit test block is run in a module even if one fails. That would
> > solve the problem quite nicely IMHO,
> 
> Which problem? That you can't get a good summary or backtrace? No
> descriptions of the unit test that failed? That other unit tests in the
> module will not run after an error? That you can't run some
> specific unit-tests only?

You get a proper error message backtrace on unit test failure. The only 
problem is that once a single unittest block within a module fails, no further 
unittest blocks within that module are run (unittest blocks from subsequent 
modules are run but no more from the one with the failure). As such, once you 
get a single failure within a module, you can't see any further failures. That 
_is_ a problem, but it's the only one that I'm aware of. And that needs to be 
fixed in the runtime, _not_ by adding more complex library support. It's a 
known issue which requires some additional support by the compiler (additional 
hooks of some kind IIRC) for the runtime to be fixed, but it is the runtime 
that should be fixed rather than trying to fix it with a library.

> > And
> > I'm against unittest blocks running any code after a single failure.
> 
> On the other hand, I think this is absolutely necessary, especially if
> you have big modules.
> 
> Imagine a high level unit-tests fails and you can't see the failure in the
> low level helper functions that nails down the error. However every library
> implemented unit test framework could just stop after the first failure, if
> configured properly. Should not be the default though.
> 
> > So, I
> > don't think that any additional unit testing framework is necessary.
> 
> I really think it is and will use one for my D code. Since both worlds
> could live together peacefully there is absolutely no reason not to include
> one in phobos.

It's one thing to use a fancier framework on your own. It's quite another to 
put it in the standard library. D's unit testing framework is designed to be 
straightforward and simple. On the whole, it does the job quite well. And once 
the issue of not running subsequent unittest blocks within a module after a 
failure in that module is fixed, I see no benefit from adding any additional 
library support. It just complicates things further.

- Jonathan M Davis