Assert and the optional Message

[H. S. Teoh]

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