Mocking is a powerful tool that I like to turn to while unit testing. Python ships with a flexible mocking package in the
unittest library called
unittest.mock. Mocks can help simplify test setup, allow you to test code that depends on features not yet implemented, and minimize undesired side effects in our test suite. I would like to show you how I use mocks in Python Django. We will cover the main reasons you would consider mocks in your unit tests, different styles of writing mocks, and common mocking anti-patterns.
Why Mock Test Dependencies
Mocks allow us to get to the point of our tests. Some parts of our codebase might be tricky to setup without introducing a lot of dependent objects. It also makes sense to mock services that we are not unit testing. Some services might have undesired consequences in a test suite. This is common when interacting with 3rd party services such as payment gateways and social media applications. In most cases we would prefer our test suite to be resilient to 3rd party service outages or dependencies. This makes tests run faster and easier to deploy to CI environments.
I also like to use mocks when practicing TDD. In these cases my mocks might even be temporary stubs that I use while the dependent service is in development. This can be extremely useful when working with other developers on the same feature. Usually you already have a good idea of what a response or input for a required service is. In those cases you can quickly mock that service and get on with writing unit tests for code that would otherwise be blocked.
Various Flavors of Mocks
Unittest mocks come in a variety of flavors. It can be a little daunting when visiting the documentation. Let’s take a look at the 4 ways I like to write mocks. For each example we will be looking at implementing a feature in a Django blog app that will allow us to post status update about a blog article to Twitter. Our code that we will be testing looks like this:
1. Mock Class
hen I first approached writing mocks in Python I went for what I thought was the most obvious pattern. Creating instances of Mocks with the generic Mock class is straightforward. In this example we create an instance of Mock and assign it to
twitter_api. We can pass
twitter_api to Post’s
post_to_twitter method and assert that the
post_update method is called with a notification about about the Post’s title.
In theory this looks good but there is a very dangerous pitfall lurking here. Mock is a little too good at faking its role. The
post_update method does not even need to exist on the instance of the
TwitterClient class that we created for this test to pass.
For this reason, I only like to use Mock in cases where I need a true test double. Usually this is early in the process of developing a new feature where the service I need is not yet available.
2. Create Autospec
We can get a little better if we use
mock.create_autospec method. This ensures that we can only call methods that are part of the Class API specification. In this example we a mock of our
TwitterClient class and then assign an instance of that class to
client. The rest of the test is pretty similar as before. However, this time the test will fail if
TwitterClient does not respond to
3. Mock Patch
The method I turn to most often when writing mocks is
mock.patch. This is a Python decorator method that can be added to each test. In this example (without even importing TwitterClient) we create a
mock_twitter_client by attaching
mock.patch with the full module path of
TwitterClient. We can then create an instance of the mock twitter client and test as before. At this stage it might also make sense to write an assertion on the return value.
4. Mock Patch Object
This example is almost identical to
mock.patch. However, by calling
object on patch we can also include the method and the return value that we are mocking. One thing to keep in mind here is that we still need to import TwitterClient into the test. With a little cut and paste it’s easy to also test what happens when the response code is something other than 200.
Mocks are a useful tool to have while unit testing. However, like most things they are not bullet proof.
When testing with mocks it’s important that you test the code that you are trying to write tests for. It seems obvious but it’s entirely possible to write a test with so many mocks that the only thing left are some meaningless assertions about code that doesn’t exist in your project.
Mocks are not substitutes for factories. When possible always use real data dependencies. Mocks really should be a last resort for times when it would be tricky to create the specific state or dependent objects that you need to write a test.
Mocks are useful for testing 3rd party services like we did throughout the examples. However, there are tools that can make testing 3rd party libraries even better. One tool I would like to explore more is VCR. The VCR library allows you to record 3rd party service responses as ‘cassettes’. From there you can interact with the service pretty much as you would in production. For each request you will received a the cached recorded response captured in your cassettes. If the API ever updates, it’s just as easy to rerecord a ‘cassette’.
I prefer not to use Mocks in my integration tests. The whole point of these types of tests is to test your entire stack and mocking any part of the stack would not be a true integration test. The only exception to this would be any interaction with a 3rd party service.
Mocking is a great tool to use in situations where supporting dependencies in a test have either undesired side effects that should be faked or when it is complicated to setup supporting dependencies in a test. Even so the need for mocking can sometimes be an indicator that the current implementation is too complex. Also, it is entirely possible to write mocks that can mislead your tests. Mocks are best used sparingly but can be a powerful tool when practicing TDD.