http://qs1969.pair.com?node_id=270303


in reply to Re: Re: Re: Testing by Contract
in thread Testing by Contract

Actually, I was chatting with iburrell about this and he was thinking of incorporating a contract in each package and having three modes. The default is to simply ignore all contracts. A second mode would be to enforce contracts and croak on failure. A third mode would check contracts and output success or failure as tests (as outlined above). This would make this a more general purporse module.

When you say that you don't "mentally file" contracts as tests, what do you mean? Design by Contract is merely a way of incorporating tests into the runtime environment. It's a natural successor to the primitive tests inherent in function signatures, but this still doesn't seem like an appropriate place for those tests. If we are going to test properly, then put tests with tests. I think, if anything, "test contracts" might bug some people because they are so used to seeing Contracts as part of the actual code as opposed to separate tests. If that's the case, then this is merely inertia.

Design by Contract was originally incorporated in Eiffel back in the late 80s. The current focus on test-driven development is changing the way people look at (and subsequently design) systems. DBC was, if anything, a precursor to test-driven development and I think it's appropriate to incorporate such a great idea into tests where, I think, it properly belongs. Others will differ with me, of course :)

Admittedly, there are certain tests that have to be in the code and cannot be removed (open FH, $foo or die $!), but contract tests may not fall into that category. The question, I think, is to identify what must remain in the code and what may cleanly be separated out into a test suite. Currently, I still have no fixed opinion on this, so I hope to see more discussion of the topic.

Cheers,
Ovid

Looking for work. Here's my resume. Will work for food (plus salary).
New address of my CGI Course.