std.unittests for (final?) review

[Michel Fortin]

On 2011-01-03 05:04:28 -0500, Jonathan M Davis <jmdavisProg at gmx.com> said:

> If a lot of people really thought that unit testing functions would be useful
> and reasonable to use inside of contracts, then it would make some 
> sense for the
> unit testing functions to no longer be in a version(unittest) block. But
> personally, I'd be a bit worried to see more than simple assertions inside of
> contracts. Contracts should be efficient, since they're going to be run 
> while the
> code is running normally, whereas unit tests don't have to worry about 
> efficiency
> quite as much. I believe that the functions that I have are efficient, 
> but I can
> easily see functions intended to aid in unit testing being totally 
> inappropriate
> in a contract due to efficiency concerns. And of course, a number of the unit
> testing functions just don't make sense in contracts regardless - like
> assertExThrown.

This makes me think of an issue. In contracts, asserts use a different 
implementation so they can work with inheritance. I believe in unit 
tests too the compiler use a different implementation too for asserts 
which gives more control to the runtime over what to do when a test 
fails (remember previous behaviour where asserts in unit tests were 
simply printing a message without aborting?). Assertions inside a 
function and inside a contract and inside a unittest block being 
different things makes me rather hesitant when I see a function 
designed to be used as a special assert in a unit test...

So given the choice between these two forms:

	unittest { assertExThrown!Exception(test); }

	unittest { assert(exThrown!Exception(test)); }

I'd choose the second just to be sure the right assertion handler is used.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/