Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Perl Testing and Quality Assurance

by Anonymous Monk
on Jun 02, 2003 at 06:18 UTC ( #262313=perlmeditation: print w/replies, xml ) Need Help??

I'm getting back to Perl programming after a decent chunk of time away from it. Looking back at my old code is making me exceptionally nervous. I haven't noticed any bugs in the last 4 months of running some of it, but I'd like to invest a little time in increasing my peace of mind so I'm looking at different testing approaches.

Looking at some of CPAN's results shows there's no shortage of module options (as I've come to expect from Perl). My question is what recommendations do the monks have for someone new to testing? Which modules should I check out? Thanks.

Replies are listed 'Best First'.
Re: Perl Testing and Quality Assurance
by adrianh (Chancellor) on Jun 02, 2003 at 06:55 UTC
Re: Perl Testing and Quality Assurance
by Zaxo (Archbishop) on Jun 02, 2003 at 08:20 UTC

    More difficult than choosing your testing toolset, you will need to decide what your tests should do. It's too late for coding to a specified test set ( which I completely agree with adrianh about - it's like magic ). Your code already exists and is in use.

    I would begin by reviewing and rewriting the documentation. That will set in mind what the user interface is supposed to be like, what the internal API is to do, and will clarify the design in your memory.

    Write user-level tests. In those, verify that the high-level documented interface works as advertised. Test erroneous usage for sanity. Then set these tests aside without fixing errors or improving anything.

    Now start devising unit test of each sub. Your documentation of internals should guide you in what each should do, what error conditions may arise, and what tolerance each shold have for those errors. Do tests of each, from the bottom up. Induce error conditions to check for correct handling. Don't forget to test global data, too.

    If your documents don't tell you what to test about a feature, that's a sign of probable hot spot. Study that closely and find out what the details should be.

    Don't be too eager to change your design, but do keep an eye open for when you must.

    After Compline,

      All excellent advice.

      Another approach to determining what your tests should do is to see what you can remove from the code.

      Just delete a line or subroutine.

      Do all your tests still pass? If so one of the following is true.

      • You need to write another test to highlight the defect in the code you've just created.
      • You've found a feature that's surplus to requirements - well done you now have a simpler code base.

      God I love unit tests :-)

      You can even automate this sort of thing if you are that way inclined (see this interview where Java's Jester is discussed for an example).

Re: Perl Testing and Quality Assurance
by dws (Chancellor) on Jun 02, 2003 at 08:29 UTC
    My question is what recommendations do the monks have for someone new to testing?

    If you're new to Unit Testing, I recommend reading one of the "walkthrough" books. You'll come away with a some new tricks in your bag, even if the target language isn't Perl.

    Kent Beck's Test Driven Design: By Example is good, as is Newkirk and Martin's Extreme Programming in Practice. (I thought this was a one-read book, but I'm now going through it a second time.) Also worthwhile is a series Ron Jeffries is working up on Test Driven Development in C#.

    Unlike many books that show only the finished product, these works show false starts and misteps, and how the authors recovered from them. They also all use JUnit (or the equivalent), but the ideas you'll pick up are readily transferable to Perl.

      All excellent reads.

      There's also some good information online. Take a poke around and the Wiki for interesting info on testing practices.

Re: Perl Testing and Quality Assurance
by gjb (Vicar) on Jun 02, 2003 at 12:02 UTC

    Probably this is obvious to all, but this is going about the wrong way round (not that you can help it, mind). The Right Way to Do It(tm) is to first write the test, then the code it's supposed to test. At least if you buy into the extreme programming philosophy and unit testing approach.

    It's better to develop tests and code in that order since at the point you write the test, it's still a black box, and you're forced to think ahead of border and corner cases. In a way, the developer is more open-minded towards his own work before he's done it than afterwards.

    Again, it doesn't apply to your particular situation, but it's something that might be worth keeping in mind for future projects. And yes, it's all in the books mentioneed above, but I like to stress it nevertheless ;-)

    And again, yes, I do program that way and enjoy it a lot.

    Just my 2 cents, -gjb-

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://262313]
Approved by vek
Front-paged by gmax
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2023-12-06 21:42 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (32 votes). Check out past polls.