in reply to Testing parameters and return values

The best way to do this is with a test suite. Testing your returns and input at run-time will cause performance degradation, and make it harder to modify the code by locking you down to how the code is written, versus what the code is supposed to do.

Test::More is a pretty standard module for writing your tests with, and once you have started down that path Devel::Cover will be invaluable to find code paths you haven't tested yet.

But what about scripts? If you refactor your scripts to be thin wrapppers around a module that you call, you can test the module and be confident the API's in your code that your script uses all work correctly and as you expect them to.

Another large benefit to testing is it makes refactoring much easier, as you can rip out and rework large sections of code without worrying about if what the code is supposed to do is broken.

Test driven development is a good subject to be familiar with, check it out. You might like it.

  • Comment on Re: Testing parameters and return values

Replies are listed 'Best First'.
Re^2: Testing parameters and return values
by tirwhan (Abbot) on Nov 04, 2005 at 21:33 UTC

    If you're worried about performance of your live code you could use Carp::Assert. Assertions will compile out if you set no Carp::Assert; and thus have no performance impact on the live code. That way you can at least perform parameter/return checking in your integration and system tests. And if there are ever any weird problems with your live code you can turn the assertions on by commenting out a single line.


    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan