On 2011-01-03 05:04:28 -0500, Jonathan M Davis <jmdavisp...@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.for...@michelf.com
http://michelf.com/
