Testing perl modules that rely on remote data

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

Replies are listed 'Best First'.
Re: Testing perl modules that rely on remote data by Corion (Patriarch) 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.	[reply]
Re: Testing perl modules that rely on remote data by morgon (Priest) 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.	[reply]
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."`	[reply] [d/l]
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.	[reply]
Re: Testing perl modules that rely on remote data by TGI (Parson) 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	[reply]
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	[reply]

Back to Seekers of Perl Wisdom