std.unittests [updated] for review

[Jonathan M Davis]

On Sunday 30 January 2011 05:13:19 Jens Mueller wrote:
> 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.

I think that it makes perfect sense for the likes of assertPred and assertThrown 
to be in the same module as enforce. They serve similar functions. It's just 
that one throws an assertError on failure, whereas the other usually throws an 
Exception.

What is odd is sticking them in a module named std.exception. But while 
assertPred might be similar to enforce, it definitely wouldn't make even less 
sense to put enforce in a module named std.unittests. I have no idea what a good 
name would be.

So, yes, it's a bit odd that std.exception would have assertPred in it, but it's 
the best fit out of all of the pre-existing modules, and std.exception does have 
semi-related functions. And honestly, I _do_ think that the size of a module 
matters. If it doesn't have enough functions in it, then it really shouldn't be 
its own module. The problem is when you have miscellaneous functions which don't 
quite fit any any module - which may be why assumeUnique and pointsTo ended up in 
std.exception.

- Jonathan M Davis