std.unittests for (final?) review

[Jens Mueller]

Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
> news:mailman.405.1294111260.4748.digitalmars-d at puremagic.com...
> > Well, it's not possible to overload assert, so that sort of thing really 
> > doesn't
> > work. You're kind of stuck with something JUnit-ish in terms of names, 
> > though
> > assertCmp and assertOpCmp both take a string for the operator, so you 
> > don't have
> > assertLessThan, assertGreaterThan, etc. And what's there uses lazy instead 
> > of
> > string mixins, because it's cleaner that way. lazy does the job just fine.
> >
> > And even if you could overload assert, you'd likely run into the same sort 
> > of
> > problems that come up when you try and overload constructors and the like 
> > and
> > the parameters aren't different enough to allow you to do all of the 
> > overloads
> > that you want to do. At least JUnit-like naming is clear, and you're only 
> > going
> > to use it unit tests, so it's fairly confined. So, if it bothers you, at 
> > least it
> > doesn't affect your actual program code.
> >
> 
> The actual name "assert" isn't really what I was getting at. I realize 
> that's not usable, and that's fine. What I meant was, for instance, your 
> documentatin includes the example:
> 
> assertOpBinary!"+"(Foo(5), 7, Foo(12));
> 
> (Although it doesn't seem to compile for me...) That's quite a mess compared 
> to the following:
> 
> assert(Foo(5) + 7 == Foo(12));

I had the same impression. But I think it should be there for
consistency reasons. Because there is also assertOpOpAssign.
But you're right in case of assertOpBinary I prefer writing
assertEqual(Foo(5) + 7, Foo(12));
Becaues it's one line and it gives enough information for me.
But this does not hold for assertOpOpAssign anymore.

> That can currently be done, of course, but it's output on failure obviously 
> doesn't give as much useful information as assertOpBinary.
> 
> I think a middle ground is needed. For instance, with the assert utils in my 
> SemiTwist D Tools library, you can do this:
> 
> mixin(deferEnsure!(`Foo(12)`, `_ == Foo(5) + 7`));
> 
> And the output upon failure still gives you this information:
> 
> Expression 'Foo(12)':
> Expected: _ == Foo(5) + 7
> Actual: 999
> 
> And, though I haven't done so yet, that can be generalized to allow it to 
> display what Foo(5) evaluated to. Admittedly, there's lots of room for 
> improvement in my syntax there, but the point is that you write an actual 
> expression and still get all the same useful information.
> 
> So, just as one off-the-top-of-my-head idea, your lib could have something 
> like:
> 
> assertExpression(`#Foo(5)# + 7 == #Foo(12)#`);
> 
> The # delimiters (or whatever system of delimiters would make sense) 
> indicate what sub-expression should be displayed, ex:
> 
> Assert failed: [Foo(5) + 7 == Foo(12)]
>     Foo(5): 6
>     Foo(12): 12
> 
> Or:
> 
> assertExpression(q(a + 7 == b}, Foo(5), Foo(12));
> // (same output as before)
> 
> The whole things may or may not need to be wrapped in a "mixin()", I don't 
> know.
> 
> Ie, something like that.

Sounds useful and could be added later.

Jens