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

palette has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I want to write automated testing suite for some .pl scripts. The scripts dont have proper subroutines defined and all the DB connections and logic in a conventional programming style.

Suggest ways to write test scripts for .pl scripts.
  • Comment on Writing unit test scripts for .pl scripts

Replies are listed 'Best First'.
Re: Writing unit test scripts for .pl scripts
by talexb (Chancellor) on May 04, 2008 at 12:50 UTC

    Are you talking about testing, using something like Test::Simple or Test::More, or are you talking about Perl::Critic, which looks at the style of your code, compares it against Damian Conway's book Perl Best Practices and tells you when there's a disagreement in style?

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      Yes, talking about testing the perl scripts using Test::Simple or Test::More.

        Ok then -- start writing tests. You'll need to set up either a test database, with the same schema as your Production database, or perhaps use something like DBD::Mock to provide canned responses for particular queries.

        Just go ahead and read the documentation on either of those Test module and come back with any questions you have. Good luck!

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Writing unit test scripts for .pl scripts
by jethro (Monsignor) on May 04, 2008 at 15:45 UTC
    Recommended read:

    Perl Testing: A Developer's Notebook
    Ian Langworth & chromatic
    O'Reilly

    Lots of code and usage examples in that book.

Re: Writing unit test scripts for .pl scripts
by stiller (Friar) on May 05, 2008 at 09:01 UTC
    I guess the best would be to start small, and avoiding changing any code before you have some basic testing to verify the work done inside the black box, and when that is in place, consider refactoring the code so that individual modules / subs can be verified.

    To do that, you could start verifying the data the script is supposed to work on is what they are supposed to be. Then that the result is what it should be for a given set of input data.

    How to do that is quite dependent on what the scripts do, and where they get the data and where they put the result. It's greatly simplified if the datasource and result locations are parameters to the script. If it's not, you might have to alter the scripts a litle to be able to give alternate params for test runs, but in such a way that other callers are not affected.

    You need to tell more about the spesifics...