std.unittests [updated] for review

[Jens Mueller]

Jonathan M Davis wrote:
> On Sunday 30 January 2011 04:13:59 Jens Mueller wrote:
> > 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.

My preference for distinct modules follows that line of separating
errors and exceptions.
The only argument against putting in its own module is it's size. That
seems to be your main point. I think putting something in new module
should mainly be concerned with separating stuff logically. Later on it
should be easy to add a new module that imports std.exception and let's
say std.assertion.
But all you say is valid. I just fear that fixing names later will be
costly. Having two modules allows us to handle this better. Just because
std.exception is already kind of messy doesn't justify putting in
there.

Jens