Mock objects essentially rule.
With them I can trick my modules into asking my mock object for the data they would receive from a call to a third object (of which I know nothing about, except for the output it returns for a given input) and they are none the wiser about it. This is incredibly easy to do, and I’m not even sure I’m using it in the best and most efficient possible way!
So I’ve basically put aside the problems of testing with live data, with all that entails about having to have a live connection to the Internet, hopping that the Flickr API is responding, having to setup test data and so on.
Some people did make the point that this way, should the Flickr API change in the future, my module will still pass all the tests and then bomb out on the poor unsuspecting users. Which, of course, is absolutely true, but it is not what module testing is about. Module testing is about making sure that the code runs as expected on the platform it is being installed on. The API may change in the future, but this is something I have to find out by myself and make the necessary changes to the modules and release them again.
So now I’ve got a bunch of modules which take the results from the Flickr::API calls and turn them into a saner structure for a few selected calls (no time to do them all so far, but I’ve got the infrastructure set up so now it is just a question of filling up the gaps). All the calls I wanted to include in the first release of the distribution are done. Now to get the higher-level modules working with these and abstracting the User, Photo and Photoset concepts and off they go to CPAN.
This is actually fun!