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.
In reply to Re: Testing perl modules that rely on remote data
by pemungkah
in thread Testing perl modules that rely on remote data
by worr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |