Developing Calliope

Debugging test failures

If a test fails, here’s a generic guide to investigating.

Start by running the test locally. Use Tox, for example, tox -e py313.

You can pass extra arguments to Pytest on the Tox commandline. Here’s an example that selects just the “foo” test and enables debug logging:

tox -e py313 -- -k foo --log-level=DEBUG

You can add breakpoints using a Python debugger. PDB is simple and is built-in to Python. Others are available. Add a breakpoint before the test failure – the interactive debug prompt should work even inside Tox and Pytest, and you can step through to see what went wrong.

Some modules have further debugging tips in the module-specific documentation.

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 test_lastfm_history.py. 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 test_musicbrainz.py, 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 test_spotify.py. 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.