Review: A new stab at a potential std.unittests

Jacob Carlborg doob at me.com
Sat Nov 20 08:03:52 PST 2010


On 2010-11-19 19:16, Jonathan M Davis wrote:
> Updated code: http://is.gd/hqPb2
>
> Okay. As mentioned before, I have helper unit test functions which I use heavily
> in std.datetime and which are pretty much going to have to either end up as
> private helper functions in std.datetime or actually get added in a separate
> module for everyone to use (I'd prefer the latter). My last post on it seems to
> have met with positive feedback overall for the basic idea but not necessarily
> the execution.
>
> In particular, needing to pass LineInfo() to assertExcThrown!() to know the file
> and line number was disliked (though it was by far the best solution that I'd
> been able to come up with). Overall, it's worked quite well, but periodically
> (for reasons that I _still_ don't understand) passing the function as an alias
> didn't work properly (sometimes the template constraint which checked that
> calling the function - exactly how it was called in the code - compiled failed,
> whereas the template would compile if the constraint was removed, which makes no
> sense at all to me). So, there were enough problems in using it and enough
> dislike for how it worked, that I mucked around with it a bit to find a better
> way to do it, and I believe that I've found one. You end up passing the entire
> function call as a string (preferably a WYSIWYG string). So, instead of
>
> assertExcThrown!(Exception, myfunc)(LineInfo(), param1, param2);
>
> you get the much shorter and cleaner
>
> mixin(assertExcThrown!(Exception, `myfunc(param1, param2)`));
>
>
> It mixes the whole thing in on that one line, so it doesn't affect the line count
> and the call is actually done at the local scope, so it's exactly as if you'd
> written the function call directly in the function (since that's how it gets
> compiled in). It also manages to deal with __FILE__ and __LINE__  internally
> this way without even needing to pass them as default parameters. The one
> downside is that - being a string mixin - it does come with higher compilation
> overhead. But that should improve as the compiler improves (
> http://d.puremagic.com/issues/show_bug.cgi?id=1382 is likely the main culprit).
>
> The list of functions is unchanged, but a few of them became eponymous templates
> to be mixed in as strings rather than being templated function calls. It is bit
> annoying to have to use mixin to do it, but the result is much cleaner on the
> whole, I believe. So, it's a huge useability change.
>
> In any case, I'm presenting the updated for your review, so tell me what you
> think.
>
> - Jonathan M Davis
>
>
> P.S. My most recent update of std.datetime doesn't use the updated unit test
> functions yet, so the only examples of how to use them are in the docs and
> source of my unittest module - both of which are included in the link above.
> I'll likely post a version of std.datetime with the updated unit tests later
> today, so if you really want to see the functions used on a larger scale, you
> can check that out then.

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?

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list