mock is a library for testing in Python. It allows you to replace parts of
your system under test with mock objects and make assertions about how they
have been used.

mock provides a core Mock class removing the need to create a host
of stubs throughout your test suite. After performing an action, you can make
assertions about which methods / attributes were used and arguments they were
called with. You can also specify return values and set needed attributes in
the normal way.

Additionally, mock provides a patch() decorator that handles patching
module and class level attributes within the scope of a test, along with
sentinel for creating unique objects. See the quick guide for
some examples of how to use Mock, MagicMock and
patch().

Mock is very easy to use and is designed for use with
unittest. Mock is based on
the ‘action -> assertion’ pattern instead of ‘record -> replay’ used by many
mocking frameworks.

Mock and MagicMock objects create all attributes and
methods as you access them and store details of how they have been used. You
can configure them, to specify return values or limit what attributes are
available, and then make assertions about how they have been used:

Mock has many other ways you can configure it and control its behaviour. For
example the spec argument configures the mock to take its specification
from another object. Attempting to access attributes or methods on the mock
that don’t exist on the spec will fail with an AttributeError.

The patch() decorator / context manager makes it easy to mock classes or
objects in a module under test. The object you specify will be replaced with a
mock (or other object) during the test and restored when the test ends:

When you nest patch decorators the mocks are passed in to the decorated
function in the same order they applied (the normal python order that
decorators are applied). This means from the bottom up, so in the example
above the mock for module.ClassName1 is passed in first.

With patch it matters that you patch objects in the namespace where they
are looked up. This is normally straightforward, but for a quick guide
read where to patch.

As well as a decorator patch can be used as a context manager in a with
statement:

Mock allows you to assign functions (or other Mock instances) to magic methods
and they will be called appropriately. The MagicMock class is just a Mock
variant that has all of the magic methods pre-created for you (well, all the
useful ones anyway).

The following is an example of using magic methods with the ordinary Mock
class:

For ensuring that the mock objects in your tests have the same api as the
objects they are replacing, you can use auto-speccing.
Auto-speccing can be done through the autospec argument to patch, or the
create_autospec() function. Auto-speccing creates mock objects that
have the same attributes and methods as the objects they are replacing, and
any functions and methods (including constructors) have the same call
signature as the real object.

This ensures that your mocks will fail in the same way as your production
code if they are used incorrectly:

I’m not however a fan of this “statically typed mocking terminology”
promulgated by Martin Fowler. It confuses usage
patterns with implementation and prevents you from using natural terminology
when discussing mocking.

I much prefer duck typing, if an object used in your test suite looks like a
mock object and quacks like a mock object then it’s fine to call it a mock, no
matter what the implementation looks like.

This terminology is perhaps more useful in less capable languages where
different usage patterns will require different implementations.
mock.Mock() is capable of being used in most of the different roles
described by Fowler, except (annoyingly / frustratingly / ironically) a Mock
itself!

How about a simpler definition: a “mock object” is an object used to replace a
real one in a system under test.