In The Problem with Mocks
we discussed some of the potential problems with mock-based tests.
In this post we’ll discuss one of the most useful, and least problematic, ways
that mock is used in the Hypothesis tests -
One of the best uses for mocks in the Hypothesis tests is through
patch is most often used when one of our modules
imports and uses another
one of our own modules.
patch replaces the other module with a
For example, h/views/api.py::create()
is the view function
that’s called when someone
POSTs a new annotation to the
https://hypothes.is/api/annotations URL. It calls the
to save the new annotation to the database.
storage has its own tests and we
don’t want our test for
create() to be accessing the real database,
so we want
storage to be replaced with a mock object. This is done using a
class TestCreate(object): def test_it_creates_the_annotation_in_storage(self, storage): ... # (Call the create() view to create an annotation) # Use the mock storage object to test that it would have saved the # annotation to storage. storage.create_annotation.assert_called_once_with(...) @pytest.fixture def storage(self, patch): # Replace h.views.api.storage with a mock object, and return the # mock object. return patch('h.views.api.storage')
The code under test,
h/views/api.py, imports another module
from h import storage
In the tests above, the
storage() fixture calls
which replaces the
storage module in
h/views/api.py with a mock object.
test_something_about_search() uses the
storage() fixture, any
code that this test calls will see a mock object in place of the real
storage() fixture happens to have the same name as the
it replaces - this isn’t necessary, the
storage() fixture could be called
anything and still replace the
storage module - but giving patch fixtures the
same name as the thing they patch is a convention in the Hypothesis tests.
patch is an unusual fixture in that it’s almost always used by other fixtures,
storage fixture above, rather than by tests directly.
patch automatically takes care to do the mocking in the best way possible:
It uses autospec so that, just like when creating a
create_autospec(), only those attributes that exist on the real object can be accessed or set on the mock (recursively). Call signatures are also matched: if code passes the wrong number of arguments, or a keyword argument that doesn’t exist on the real method, to a mock object from the
patchfixture it’ll get a
TypeErrorjust as you would get from the real object.
patchalso takes care of stopping the patch after the test method finishes, before the next test is run, so that one test’s mock object doesn’t leak into other tests.
It still isn’t perfect (see The Problem with Mocks
for the limitations of autospeccing)
patch is one of the most useful and least
problematic applications of the mock library and you’ll see it used a lot in
the Hypothesis tests.
In the next post we’ll look at a pytest feature that’s often used in combination with patch - the usefixtures decorator.