Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: using Test::* modules for generic testing of non perl stuff?

by biosysadmin (Deacon)
on Oct 15, 2004 at 20:35 UTC ( #399653=note: print w/ replies, xml ) Need Help??


in reply to using Test::* modules for generic testing of non perl stuff?

If your stuff is command-line based, why not just use backticks to capture the output of some shell commands in your test scripts? Simply generate some acceptable output and compare it to the dynamic output generated by your test script. I've misused the Test::* modules to test non-code things (such as DNS MX configurations) and it's usually very effective.

Can you be more specific on exactly what you're trying to do, how you want to do things and what you've tried? I think this is a great idea, it's just difficult to give advice without more specifics.


Comment on Re: using Test::* modules for generic testing of non perl stuff?
Re^2: using Test::* modules for generic testing of non perl stuff?
by jfroebe (Vicar) on Oct 15, 2004 at 20:49 UTC

    some is command line based but I'm trying to avoid calling os commands directly if possible (hetergenous environment where output isn't always the same for the same commands). I would prefer to use pure perl where possible.

    Can you elaborate on your misuse of the Test::* modules for testing non code things? Specifically why it was 'misused'. I'm trying to come up with pros and cons as well for the use of Test::* for non-code things.

    Jason L. Froebe

    No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

      I used the word "misuse" because I think that the Test::* modules were originally used for testing code, and I've adapted them to some orthogonal uses.

      At it's most fundamental, you just need to define a set of "things" you want to test and define their acceptable output. This can be tricky, as you might need to define a range of acceptable output values. One strategy that I've used in the past is to predefine a hash like this:

      %commands = { $cmd1 => $output1, ... };
      Then execute the commands and test the dynamic output against the predefined output.

      I've actually got to run and catch a plane, but I'll be sure to check on this thread when I get back. Cheers. :)

        I understand where you're coming from now. I *think* the Test::* should work okay as long as I code a pass/fail. What I do like is the fact that the Test::* are already built and are relatively simple to use. I agree that depending on what I'm testing, I might have to shoehorn it.

        I guess I'm looking for reasons NOT to use it.. At this point, I see only that some extra coding of the test may only need to be done.. But since I've fallen for too good to be true with some perl modules on cpan before (fits my need but no maintainer, doesn't fit my need exactly but maintainer goes ballistic when I submit a patch extending it without getting permission first from the maintainer to modify the module in the first place for my own use, etc.), I'm skeptical

        Jason L. Froebe

        p.s. Hava a good flight! No delays!

        No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://399653]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (9)
As of 2014-11-25 22:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (160 votes), past polls