Helper unit testing functions in Phobos (possible std.unittests)

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.129.1289031502.21107.digitalmars-d at puremagic.com...
> On Friday 05 November 2010 22:54:20 Nick Sabalausky wrote:
>>
>> I made a very similar thing in my SemiTwist D Tools library, so I can
>> definitely attest to D's need for all of this.
>>
>> My comments on this one, based on a breif skim of the doc:
>>
>> I would try to change it so this:
>>
>> assertOpCmp!("<")(myfunc(), 7, "My test failed!");
>>
>> Can be written more like these:
>>
>> assert!("_ < 7", "myfunc()", "My test failed!")();
>> assert!("_1 < _2", "myfunc()", "7", "My test failed!")();
>> assert!("_1 < _2", "myfunc()", "somethingElse()", "My test failed!")();
>>
>> Aside from being more flexible, this way when it fails it can report much
>> more relevent information that can actually compete with JUnit/NUnit. For
>> instance, even with the custom message omitted, it could still give info
>> like:
>>
>> Failed: 'myfunc() < 7'
>> 'myfunc()' was '13'
>
> I don't really see the benefit of this. As it is, assertOpComp!() clearly 
> tells
> you what the actual result was and what the values were.

I see, I didn't know that.


>> Also, I'd say if file/line info can't be inferred automatically because 
>> of
>> varargs, then the interface needs to lose the vararg ability. It'd be 
>> nice
>> to have, but not needing to provide line/file info manually is much 
>> nicer.
>> Although, we could probably have both by using the suggestion above (ie,
>> make the whole thing generate a string to be mixed-in).
>
> We need the ability to call arbitrary functions with some of the unit test
> functions (the ones where you have to pass LineInfo()). I don't see how 
> you
> could do that with a string mixin unless you made the test itself a mixin
> instead of a function call, which strikes me as quite unpleasant.

No more unpleasant than LineInfo(), and it also opens the door for other 
improvements.


>
>> Do the 'assertEqual', 'assertOpCmp', etc, all report if an exception was
>> thrown (and if so, what exception)? If not, they should.
>
> They throw just like assert would. Even assertExcThrown() throws the 
> exception
> if it's not the type of exception that you were testing for. I see no 
> benefit in
> having them catch stray exceptions. That's not what they're testing for, 
> and I
> believe that just like with assert, if a unit test function fails, that 
> should
> be the end of that unit test.
>

STRONGLY disagree here. (Mentioned more about it in a different branch of 
this thread.)