Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Testing perl modules that rely on remote data

by worr (Novice)
on Aug 01, 2010 at 18:38 UTC ( #852360=perlquestion: print w/ replies, xml ) Need Help??
worr has asked for the wisdom of the Perl Monks concerning the following question:

Hey PerlMonks!

I'm writing a Perl module that uses a popular social networking website. Obviously I'd like to write some good unit tests so that I can verify that my code works, but I'm at a loss at the best way to do this.

Since data on the site has a tendency to fluctuate often, what kind of stuff should I do to set up my tests? Should I some of the methods test against my own account and hope the expected results don't change?

Also, I use Moose in my Perl module, but should I really bother testing the methods that it writes for me?

I'm new to Perl testing, so any help would be appreciated.

Thoughts?

Comment on Testing perl modules that rely on remote data
Re: Testing perl modules that rely on remote data
by Corion (Pope) on Aug 01, 2010 at 19:13 UTC

    My approach to testing "online sites" is to copy the HTML and to test against that locally. That way, your tests don't deliver bogus messages just because the network is unreachable or the site is down for maintenance. You could distribute the online tests separately, or only run them when an environment variable is set, to verify that the site does not change behind your back.

Re: Testing perl modules that rely on remote data
by Utilitarian (Vicar) on Aug 01, 2010 at 20:36 UTC
    Slightly "me too"-ish comment, but I maintain a series of platform check modules for a set of services that depend on an X500 server, my test routines assume that NET::LDAP and IO::Socket work and the modules have internal method tests which use potted return values which test as many edge cases as I can think of

    print "Good ",qw(night morning afternoon evening)[(localtime)[2]/6]," fellow monks."
Re: Testing perl modules that rely on remote data
by morgon (Deacon) on Aug 02, 2010 at 01:17 UTC
    Since data on the site has a tendency to fluctuate often, what kind of stuff should I do to set up my tests? Should I some of the methods test against my own account and hope the expected results don't change?

    If you have a good design (buzzword: dependency injection) you could use Mock-objects for your test-cases that replace the classes that do the actual network-access and return defined test-data.

    In this way the tests for your "business logic" do not break when a site changes.

    Test::MockObject can help a lot for such things.

Re: Testing perl modules that rely on remote data
by pemungkah (Priest) on Aug 02, 2010 at 21:43 UTC
    Mojo, specifically Mojolicious, is aces when it comes to this kind of testing.

    In Mojolicious, you can create routes, which are essentially regexes that match URLs, with a sub associated with each one that gets called. It's usually a pretty simple process to create a route for each of the server states you want to generate (even 404s, 500 server errors, timeouts, etc.) the output you want at the client from text. This means the Mojo mock server is dumb as a bag of hammers, but can return the right thing for the right URL.

    You can now write a client that responds properly to this mock server; once that's working, you can then test the client against the real server as a backstop. If the test vs. the real server fails, you can now see whether it's because the server's doing something unexpected or not by rerunning the test vs. the mock server. If that passes but the real server fails, you know that the problem's in the data that the client is getting, not the client itself (unless your mock server is seriously out of spec vs. the real server; continuous integration will help keep this from happening, as you'll see any changes as early as possible).

    The nice thing is that as long as you make sure that any server output changes (note I did not say "server changes" - as long as the output is the same, the mock server doesn't need an update, no matter how the backend is shuffled - using an MVC model in the server will help with this a LOT).

    As far as testing generated methods goes, I would - but only because any code I have actually tested and verified to work is yet another thing I don't have to look at when debugging a problem. Investing 5 or 10 minutes initially turns into a lot of savings each time you have to debug something that might be broken if the data you wanted your method to store wasn't stored properly.

Re: Testing perl modules that rely on remote data
by stvn (Monsignor) on Aug 04, 2010 at 16:46 UTC
    Also, I use Moose in my Perl module, but should I really bother testing the methods that it writes for me?

    No, Moose has that covered pretty well with the Moose and Class::MOP test suites.

    -stvn
Re: Testing perl modules that rely on remote data
by TGI (Vicar) on Aug 06, 2010 at 05:58 UTC

    There's some good discussion of testing Moose generated methods in this StackOverflow post.


    TGI says moo

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://852360]
Approved by BioLion
Front-paged by BioLion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2014-12-21 05:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (103 votes), past polls