From edc3929dafe73dfb4f7d2b59711c7ab57b2df618 Mon Sep 17 00:00:00 2001 From: jcass Date: Wed, 20 Jan 2016 11:49:29 +0200 Subject: [PATCH] docs:address PR review comments. --- docs/extensiondev.rst | 48 ++++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 16 deletions(-) diff --git a/docs/extensiondev.rst b/docs/extensiondev.rst index c208a092..348082fd 100644 --- a/docs/extensiondev.rst +++ b/docs/extensiondev.rst @@ -576,6 +576,7 @@ part of the extension. Testing the extension definition -------------------------------- + Test cases for checking the definition of the extension should ensure that: - the extension provides a ``ext.conf`` configuration file containing the @@ -589,20 +590,20 @@ An example of what these tests could look like is provided below:: ext = Extension() config = ext.get_default_config() - self.assertIn('[my_extension]', config) - self.assertIn('enabled = true', config) - self.assertIn('param_1 = value_1', config) - self.assertIn('param_2 = value_2', config) - self.assertIn('param_n = value_n', config) + assert '[my_extension]' in config + assert 'enabled = true' in config + assert 'param_1 = value_1' in config + assert 'param_2 = value_2' in config + assert 'param_n = value_n' in config def test_get_config_schema(self): ext = Extension() schema = ext.get_config_schema() - self.assertIn('enabled', schema) - self.assertIn('param_1', schema) - self.assertIn('param_2', schema) - self.assertIn('param_n', schema) + assert 'enabled' in schema + assert 'param_1' in schema + assert 'param_2' in schema + assert 'param_n' in schema def test_setup(self): registry = mock.Mock() @@ -616,10 +617,11 @@ An example of what these tests could look like is provided below:: Testing backend actors ---------------------- + Backends can usually be constructed with a small mockup of the configuration file, and mocking the audio actor:: - @pytest.fixture() + @pytest.fixture def config(): return { 'http': { @@ -641,10 +643,17 @@ file, and mocking the audio actor:: def get_backend(config): return backend.MyBackend(config=config, audio=mock.Mock()) +The following libraries might be useful for mocking any HTTP requests that +your extension makes: -You'll probably want to patch ``requests`` or any other web API's that you use -to avoid any unintended HTTP requests from being made by your backend during -testing:: +- `responses `_ - A utility library for + mocking out the requests Python library. +- `vcrpy `_ - Automatically mock your HTTP + interactions to simplify and speed up testing. + +At the very least, you'll probably want to patch ``requests`` or any other web +API's that you use to avoid any unintended HTTP requests from being made by +your backend during testing:: from mock import patch @mock.patch('requests.get', @@ -654,7 +663,9 @@ testing:: Backend tests should also ensure that: - the backend provides a unique URI scheme, -- that it sets up the various providers (e.g. library, playback, etc.):: +- that it sets up the various providers (e.g. library, playback, etc.) + +:: def test_uri_schemes(config): backend = get_backend(config) @@ -675,18 +686,21 @@ special setup or processing. Testing libraries ----------------- + Library test cases should cover the implementations of the standard Mopidy API (e.g. ``browse``, ``lookup``, ``refresh``, ``get_images``, ``search``, etc.) Testing playback controllers ---------------------------- + Testing ``change_track`` and ``translate_uri`` is probably the highest priority, since these methods are used to prepare the track and provide its audio URL to Mopidy's core for playback. Testing frontends ----------------- + Because most frontends will interact with the Mopidy core, it will most likely be necessary to have a full core running for testing purposes:: @@ -700,8 +714,9 @@ you are familiar with ``ThreadingActor``, ``ThreadingFuture``, and the ``proxies`` that allow you to access the attributes and methods of the actor directly. -You'll also need a list of ``models.Track`` and a list of URIs in order to -populate the core with some simple tracks that can be used for testing:: +You'll also need a list of :class:`~mopidy.models.Track` and a list of URIs in +order to populate the core with some simple tracks that can be used for +testing:: class BaseTest(unittest.TestCase): tracks = [ @@ -738,6 +753,7 @@ the end of most method calls in order to get to the actual return values. Triggering events ----------------- + There may be test case scenarios that require simulating certain event triggers that your extension's actors can listen for and respond on. An example for patching the listener to store these events, and then play them back for your