std.unittests for (final?) review

[Jens Mueller]

Jonathan M Davis wrote:
> 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.

What do you mean by "running normally"? I think since they are compiled
away with -release they are not run normally.

> 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.

I think you're right. It definitely should stay in it's own module. I do
it as follows:
Build with -release -noboundscheck and no -unittest to get the
production version. I.e. all contracts, asserts, boundschecks, and
unittests go away.
Further I have a build with -unittest which is for testing. Now I can
use Jonathan's assertions with better error messages even in contracts.

Jens