std.unittests [updated] for review

Jonathan M Davis jmdavisProg at gmx.com
Sun Jan 30 04:44:24 PST 2011


On Sunday 30 January 2011 04:13:59 Jens Mueller wrote:
> Masahiro Nakagawa wrote:
> > I vote Andrei's suggestion, std.exception is better than new
> > std.unittests. I think testing module should provide more features(e.g.
> > Mock, Stub...). Your helpers help assert writing style but not help
> > testing.
> > In addition, std.exception already defined similar functions.
> 
> I do not like putting it in std.exception. Maybe the name std.unittest
> is also not good. I would propose std.assert if assert wasn't a keyword.
> When I use std.exception I want to handle situations that are part of
> the spec (i.e. exceptions) whereas Jonathan's module helps me writing
> asserts (that's most of the time unittests).
> Basically it helps me verifying behavior according to a spec. I want to
> keep the dichotomy of errors and exceptions. Putting both things in one
> module is rather strange to me. What are the arguments for putting it in
> std.exception? I find the size a rather weak argument. I thought about
> providing an assertDeath ones std.process is redone.
> And even though enforce and assert are mirroring each other they are
> used in different contexts. I would _not_ expect helpers for writing
> assertions (Assert_Error_) in a module named std.exception.

Would you expect assumeUnique or pointsTo to be in std.exception? I sure 
wouldn't, but for whatever reason, they're there. std.exception is a bit of a an 
odd module anyway. enforce and collectException are the only two which are 
exception related, and there aren't many functions in there at all.

collectExceptionMsg, which is one of my proposed functions, definitely belongs in 
std.exception, since it's similar to collectException. The others are more 
debatable. They all throw AssertErrors on failure, and two of them - 
assertThrown and assertNotThrown - test for exceptions, but they aren't really 
exception-related overall. However, std.exception is by far the best fit of the 
currently existing modules, and enforce is essentially an assert that throws an 
exception instead of an AssertError, and it's in std.exception.

So, yeah. It's a bit odd to stick them in std.exception, but std.exception is 
already rather odd, and if we don't want to create a new module, it's by far the 
best place to put them. And unless we forsee added a bunch of new unit testing 
functions to Phobos, creating a new std.unittests would mean having a pretty 
small module. Ignoring overloads, std.unittests would have only 4 functions in 
it. And if we put collectExceptionMsg in std.exception where it belongs, then 
std.unittests would have only 3 functions. And unless we really expect a bunch 
of new unit testing functions, that really doesn't seem like a good idea to me. 
And virtually every unit testing function that I've come up with has been merged 
into assertPred. So, don't forsee there being much in the way of additions to 
std.unittests unless someone comes up with something drastically different which 
makes it into Phobos.

So, while I don't think that std.exception is a great fit, I do think that it's a 
reasonable fit. If anything, I think that it would be better to come up with a 
better name for std.exception than it would be to stick my new functions in a 
separate module. But we _already_ rename std.contracts to std.exception, so that 
would mean renaming that module _again_, and I have no idea what a better name 
would be anyway.

- Jonathan M Davis


More information about the Digitalmars-d mailing list