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


in reply to Testing by Contract

This is so obvious that I must have missed something. (caller 1)[3] has the caller's package and you could specify a protocol where the contract exists in __PACKAGE__ . "::Contract". So from your test code you'd say use Contract::File; and in Contract::File your import() would fetch the caller's package.

So now that I've publicly misunderstood your question, what did you mean again?

Replies are listed 'Best First'.
Re: Re: Testing by Contract
by Ovid (Cardinal) on Jun 30, 2003 at 19:26 UTC

    I think what you're saying is that I have the Contract::File use or require everything that should be tested and then it can handle attaching the contracts because it knows that the methods are in the symbol table? That seems pretty clear and I should have thought of that sooner. I was so focused on my test contract idea that I managed to make this look harder than I thought :)

    That's seems like a good strategy. Any thoughts on the validity of the actual concept of test contracts?

    Cheers,
    Ovid

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

      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?

        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.