CURL Wrapper: Congratulations Next up: std.serialize

Tobias Pankrath tobias at pankrath.net
Fri Dec 30 04:41:37 PST 2011


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?

> 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.







More information about the Digitalmars-d mailing list