std.unittests for (final?) review

[Jonathan M Davis]

On Monday 03 January 2011 01:38:29 Vladimir Panteleev wrote:
> On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > So, please have a look at the code.
> 
> Just one thing: wouldn't these functions also be useful in contract
> programming (invariants etc.)? Perhaps they should just be added to
> std.exception?

Well, they're written with unit tests in mind rather than contracts. Unit tests 
and contracts have similar but different purposes. I wouldn't really want to 
conflate the two. Also, it's std.exception now rather than std.contracts 
specifically because it doesn't really relate to contracts, so even if you did 
want to use unit testing functions in contracts, I'm not sure that std.exception 
is the right place to put such functions anyway.

As it stands, the entire module is in a version(unittest) block, so the 
functions can't be used outside of unit tests.

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.

Howevr, regardless of whether the functions are deemed reasonable for use in 
contracts, I do think that having a module of functions designed specifically for 
use in unit tests is of definite value, and regardless of the current size of the 
module, it's quite possible that it could become fairly large at some point if 
enough useful unit testing functions are devised. Merging that in with 
std.exception seems ill-advised to me. Not to mention, it's a lot more obvious 
that you're dealing with functions intended to aid in unit tests when the module 
is named std.unittests than if those functions are lumped in with the stuff in 
std.exception.

- Jonathan M Davis