What a nice solution...thanks for sharing.
For my module I don't have to handle state changes at the Stripe end. Not unless I implement shipping plans which is possible but not a high priority. Therefore, I've set up a script on my server that can provide a valid session object or a Stripe style error response. That way I can test for both scenarios. I've only implemented the success test so far but the fail will follow. There is a new (undocumented) url parameter that the tests use to access the test server.
Being done over HTTP to a live server means that testing can happen without having to install Test::LWP::UserAgent on the target machine. I just hope that 20 billion people don't decide to install the module simultaneously!!!
The tests are now split accross four files:
00-load.tt
01-trolley.tt
02-stripe.t
03-stripe-live.t
02 tests against the Stripe server and, of course, fails. 03 tests against my server so it should be able to get a live connection.
Update:
Turns out it is not that simple! As always...
A check was added that an HTTP request gets a 200 status code and skips the live server tests if not. The network could be down at install time or it could be installed on a machine with no network connection - little point but folk do strange things!
I was finding that more often than not the tests were being skipped. Turns out something in the request is tripping the server monitoring systems and blocking my IP address for anything from a couple of minutes to half an hour. So the live tests have been disabled in the test file until I can find what is causing this problem.
The obvious things have been tried. Removing the Authorization header from the test request and ensuring the POST command doesn't have an empty payload. Time to scratch my head and search for inspiration... | 