Developing Calliope

Tests for web service integration

Automated tests should not run against a real web service, for reliability and performance reasons. Here are examples of how web APIs can be mocked in Calliope test suite. There are several methods, as most integrations use a third-party helper library rather than talking directly to the remote service.

Run a local HTTP server

This method is used by Python wsgiref.simple_server runs a real HTTP server, and the address is passed to cpe lastfm-history command with the --server argument.

Override the urllib Opener class

This method is used by, adapted from the testsuite of the Python musicbrainzngs module. An internal function from musicbrainzngs is monkeypatched to use our custom URL opener. Testcases supply a map of URL patterns as regular expressions and functions which simulate the response.

Override the public API of the client library

This method is used by The whole calliope.spotify.SpotifyContext class is replaced with a unittest.mock.Mock instance, allowing us to replace the Spotipy client library completely with our own functions.

Tracker module: debugging test failures

Reproducing test failures from the test_tracker_search test is not trivial.

First, modify the tracker_miner_fs_sandbox() fixture and comment the rmtree calls so the test data is preserved, and print its location.

Now, you can use the tracker3 CLI commands such as export and sparql to inspect the store. If the store tmpdir was tmp/tracker-indexed-tmpdirerdtqnw9/ you could run this to dump all data:

tracker3 export –database /tmp/tracker-indexed-tmpdirerdtqnw9/cache/tracker3/files/

You can also use the tracker-sandbox utility with the –store and –index-recursive-directories options to open a shell with running Tracker Miners process which you can run cpe commands against.