Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: Re: Re: Testing by Contract

by diotalevi (Canon)
on Jun 30, 2003 at 20:03 UTC ( [id://270297]=note: print w/replies, xml ) Need Help??


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

I'd like there to be a cleaner conceptual break from 'testing' and contracts. I could understand the contracts being incorporated into testing but I don't mentally file them that way and it'd be a shame to have a general purpose module that acts on functions with unrelated bits stuck in.

The overall idea, I like. Contract::File::Test might have your testing-specific code in it. My assumption is that in using this sort of thing that the module user would be using things like Params::Validate and throwing exceptions somehow. Maybe Exception::Class as well. Or how to signal contract failure?

Replies are listed 'Best First'.
Re(4): Design by Contract was ahead of its time
by Ovid (Cardinal) on Jun 30, 2003 at 20:19 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://270297]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (5)
As of 2024-04-24 03:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found