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