std.unittests [updated] for review

Jens Mueller jens.k.mueller at gmx.de
Mon Jan 31 01:41:10 PST 2011


Andrei Alexandrescu wrote:
> On 01/30/2011 06:13 AM, 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.
> >
> >Jens
> 
> assertThrows and its converse are a good fit for std.exception. Then
> we're left with a couple of concepts that don't deserve their own
> module and are difficult to fit elsewhere. I reckon that in a
> perfect world there would be a better match, but I don't cringe at
> the thought of std.exception holding them.

I going to get used to it. I'll guess I just don't want to loose the
concept of errors vs. exceptions.

Jens


More information about the Digitalmars-d mailing list