Review: A new stab at a potential std.unittests

[Jacob Carlborg]

On 2010-11-21 01:23, Jonathan M Davis wrote:
> On Saturday 20 November 2010 08:03:52 Jacob Carlborg wrote:
>> Why don't you use delegates instead of string mixins? For example,
>> assertExcThrown, could take a delegate which calls the function you want
>> to test instead of a string that represents the call. The mixin want be
>> needed as well. Am I missing something?
>
> Well, delegates wouldn't be a bad idea, but they're unwieldy too. Would you
> rather write
>
> assertExcThrown!Exception((){func(param1, param2);});
>
> or
>
> mixin(assertExcThrown!(Exception, `func(param1, param2)`));

I would go with the delegate, but when you format the code like that it 
doesn't look any good (btw, no need for the extra pair of empty 
parentheses). I think this looks better:

assertExcThrown!Exception({
     func(param1, param2);
});

And BTW, D needs a better way to pass a delegates to a function, 
something like the syntax that can be used in Scala:

assertExcThrown!Exception {
     func(param1, param2);
}

I think that someone has talked about this syntax before on this mailing 
list.

> The delegate would be less efficient, but you could reduce code duplication by
> going that route, since then __FILE__ and __LINE__ could be default parameters
> to assertExcThrown!(). It would also make it so that __FILE__ and __LINE__ could
> be replace if you reall wanted to (which could be useful), but you could do that
> by changing it so that the mixin version of assertExcThrown!() took __FILE__ and
> __LINE__ as default parameters instead of them being internal to the mixin.
> Neither is pretty, but they both have their pros and cons. It looks like if I do
> keep the mixin version, I should probably move __FILE__ and __LINE__ to
> parameters instead of mixing them in directly, so that it's more flexible. I
> suppose that you could just make the function call parameter a lazy one and
> templatize assertExcThrown!() on the return type of the function (I _think_ that
> that would still work with void). That way, you could avoid having to type (){;}
> around the function call. In a way though, it is a bit silly to declare it as
> lazy, since it _always_ gets called. That could be the best way to go though.
>
> Honestly, it never even occurred to me to make it a delegate. I was originally
> trying to pass the function and its arguments separately, and that didn't work
> as well as I'd have liked, and the mixin solution is what I arrived at. I do find
> having to pass a delegate uglier than having to use a mixin, but that's probably
> pretty subjective and debatable. Using delegates will make for less efficient unit
> tests, but it would mean less code duplication, and thus faster compilation. So,
> it's not entirely a straightforward choice, I think.

I guess you're right and I would choose the delegates.

> The lazy solution sounds pretty good actually. Can anyone think of any real
> downsides to that? So, it would look something like
>
> assertExcThrown(E : Throwable, T)(lazy T, string file = __FILE__, size_t line =
> __LINE__);
>
> - Jonathan M Davis

-- 
/Jacob Carlborg