What about debug vs release compilation for this new module? We know we have assert for debug mode, and enforce for release mode (except the special assert false case). If I want assertExcThrown to be compiled in release mode it seems I'd need an enforced version of it, possibly called enforceExcThrown that uses enforce internally.
I'd prefer if we could somehow mark assert's to be compiled in release mode instead of having to duplicate code for assert and enforce versions of these new unittest functions. On 11/20/10, Jacob Carlborg <d...@me.com> wrote: > 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 >
