On Sat, Mar 10, 2012 at 11:09:04AM -0800, Jonathan M Davis wrote:
> On Saturday, March 10, 2012 09:04:42 H. S. Teoh wrote:
[...]
> > Hmm. The more I think about it, the more I'm leaning towards
> > simplifying contracts so that most, if not all, of any complicated
> > checks happen in an external function (i.e. outside the contract),
> > which can be unittested separately. Unittesting things that throw
> > assertion errors is just a minefield rife with potentially very
> > nasty problems.
>
> If you really want to be testing your tests, then it probably does
> make a lot of sense to use separate functions for them which you can
> then unit test. And assuming that the compiler will let you, if you
> wanted to, you could then templatize them on exception type and use
> enforce rather than assert. So, in the contracts themselves, you do
> testFunc!AssertError(args), but in the tests you do
> testFunc!MyException(args). If there are definitely no destructors,
> scope statements, and finally blocks in your test functions though,
> you might as well just catch AssertError.
[...]
My point was that contracts won't *need* to be tested at all, if all
they do is call a couple o' functions to do the actual complicated
verification. You can then just unittest said functions, and be assured
that the contract does what you think it does.
bool veryComplicatedVerification(real[] args, real result) {
...
}
unittest {
assert(veryComplicatedVerification(sample_data,
known_good_result));
assert(!veryComplicatedVerification(sample_data,
known_bad_result));
}
real veryComplicatedComputation(real[] args)
out(result) {
assert(veryComplicatedVerification(args, result));
} body {
auto result = lotsOfDotDotDotMagic(args);
return result;
}
T
--
If you compete with slaves, you become a slave. -- Norbert Wiener
