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.

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.

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.

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.

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