in reply to Being more Assert-ive with Perl

It is not enough to have perl complain the first time I try to do $arg->{"key"} on an array ref. I want to catch things prior to that, and not allow any part of my methods to be run unless it receives the proper input.

Design By Contract does not seem to solve the problem, it only makes language translator complain a little earlier, does it? We need to test the code with both correct and incorrect input values in any case.

Replies are listed 'Best First'.
Re^2: Being more Assert-ive with Perl
by stvn (Monsignor) on Sep 17, 2004 at 15:09 UTC
    Design By Contract does not seem to solve the problem, it only makes language translator complain a little earlier, does it?

    Yes, but nothing can solve that problem really, since its "user error". I forgot where I heard it, but I have always like the quote: "Complain early and often" when speaking about error handling.

    We need to test the code with both correct and incorrect input values in any case.

    I agree. My point is that you can efficiently create those tests using this style and not have the overhead of full blown conditional blocks.

    -stvn
[reply]

      Hm. Imagine a tool that takes all our declared contracts and composes a huge test suite that tries to test whether each contract is respected in our code, say, by feeding a series of valid and invalid data and turning off all runtime contract checks.

      E.g. I declare that my complex compute_graviton_phasor_coefficient sub wants to take a positive prime number as argument. Now I'd like to get a test that will run it against random numbers and testing that it dies in the right places.

      And, putting dreams aside, I'm going now to read about specification testing and try Test::LectroTest :)

[reply]
[d/l]
        Hm. Imagine a tool that takes all our declared contracts and composes a huge test suite that tries to test whether each contract is respected in our code, say, by feeding a series of valid and invalid data and turning off all runtime contract checks.

        I like the idea of a tool, but why turn off all runtime contract checks? Wouldn't you want them in there to catch the errors?

        And, putting dreams aside, I'm going now to read about specification testing and try Test::LectroTest :)

        Me too, Test::LectroTest looks very cool.

        -stvn
[reply]

In Section Meditations