22 Apr 2021 · Software Engineering

    Getting Started with Mocking in Python

    9 min read
    Contents

    Introduction

    Mocking is simply the act of replacing the part of the application you are testing with a dummy version of that part called a mock.

    Instead of calling the actual implementation, you would call the mock, and then make assertions about what you expect to happen.

    What are the benefits of mocking?

    • Increased speed — Tests that run quickly are extremely beneficial. E.g. if you have a very resource intensive function, a mock of that function would cut down on unnecessary resource usage during testing, therefore reducing test run time.
    • Avoiding undesired side effects during testing — If you are testing a function which makes calls to an external API, you may not want to make an actual API call every time you run your tests. You’d have to change your code every time that API changes, or there may be some rate limits, but mocking helps you avoid that.

    Prerequisites

    You will need to have Python 3.3 or higher installed. Get the correct version for your platform here. I will be using version 3.6.0 for this tutorial.

    Once you have that installed, set up a virtual environment:

    python3 -m venv venv

    Activate the virtual environment by running:

    source venv/bin/activate

    After that, add a main.py file where our code will reside and a test.py file for our tests.

    touch main.py test.py

    Basic Usage

    Imagine a simple class:

    class Calculator:
        def sum(self, a, b):
            return a + b

    This class implements one method, sum that takes two arguments, the numbers to be added, a and b. It returns a + b;

    A simple test case for this could be as follows:

    from unittest import TestCase
    from main import Calculator
    
    class TestCalculator(TestCase):
        def setUp(self):
            self.calc = Calculator()
    
        def test_sum(self):
            answer = self.calc.sum(2, 4)
            self.assertEqual(answer, 6)

    You can run this test case using the command:

    python -m unittest

    You should see output that looks approximately like this:

    .
    _____________________________________________________________
    
    Ran 1 test in 0.003s
    
    OK

    Pretty fast, right?

    Now, imagine the code looked like this:

    import time
    
    class Calculator:
        def sum(self, a, b):
            time.sleep(10) # long running process
            return a + b

    Since this is a simple example, we are using time.sleep() to simulate a long running process. The previous test case now produces the following output:

    .
    _____________________________________________________________
    
    Ran 1 test in 10.003s
    
    OK

    That process has just considerably slowed down our tests. It is clearly not a good idea to call the sum method as is every time we run tests. This is a situation where we can use mocking to speed up our tests and avoid an undesired effect at the same time.

    Let’s refactor the test case so that instead of calling sum every time the test runs, we call a mock sum function with well defined behavior.

    from unittest import TestCase
    from unittest.mock import patch
    
    class TestCalculator(TestCase):
        @patch('main.Calculator.sum', return_value=9)
        def test_sum(self, sum):
            self.assertEqual(sum(2,3), 9)

    We are importing the patch decorator from unittest.mock. It replaces the actual sum function with a mock function that behaves exactly how we want. In this case, our mock function always returns 9. During the lifetime of our test, the sum function is replaced with its mock version. Running this test case, we get this output:

    .
    _____________________________________________________________
    
    Ran 1 test in 0.001s
    
    OK

    While this may seem counter-intuitive at first, remember that mocking allows you to provide a so-called fake implementation of the part of your system you are testing. This gives you a lot of flexibility during testing. You’ll see how to provide a custom function to run when your mock is called instead of hard coding a return value in the section titled Side Effects.

    A More Advanced Example

    In this example, we’ll be using the requests library to make API calls. You can get it via pip install.

    pip install requests

    Our code under test in main.py looks as follows:

    import requests
    
    class Blog:
        def __init__(self, name):
            self.name = name
    
        def posts(self):
            response = requests.get("https://jsonplaceholder.typicode.com/posts")
    
            return response.json()
    
        def __repr__(self):
            return '<Blog: {}>'.format(self.name)

    This code defines a class Blog with a posts method. Invoking posts on the Blog object will trigger an API call to jsonplaceholder, a JSON generator API service.

    In our test, we want to mock out the unpredictable API call and only test that a Blog object’s posts method returns posts. We will need to patch all Blog objects’ posts methods as follows.

    from unittest import TestCase
    from unittest.mock import patch, Mock
    
    
    class TestBlog(TestCase):
        @patch('main.Blog')
        def test_blog_posts(self, MockBlog):
            blog = MockBlog()
    
            blog.posts.return_value = [
                {
                    'userId': 1,
                    'id': 1,
                    'title': 'Test Title',
                    'body': 'Far out in the uncharted backwaters of the unfashionable  end  of the  western  spiral  arm  of  the Galaxy\ lies a small unregarded yellow sun.'
                }
            ]
    
            response = blog.posts()
            self.assertIsNotNone(response)
            self.assertIsInstance(response[0], dict)

    You can see from the code snippet that the test_blog_posts function is decorated with the @patch decorator. When a function is decorated using @patch, a mock of the class, method or function passed as the target to @patch is returned and passed as an argument to the decorated function.

    In this case, @patch is called with the target main.Blog and returns a Mock which is passed to the test function as MockBlog. It is important to note that the target passed to @patch should be importable in the environment @patch is being invoked from. In our case, an import of the form from main import Blog should be resolvable without errors.

    Also, note that MockBlog is a variable name to represent the created mock and can be you can name it however you want.

    Calling blog.posts() on our mock blog object returns our predefined JSON. Running the tests should pass.

    .
    _____________________________________________________________
    
    Ran 1 test in 0.001s
    
    OK

    Note that testing the mocked value instead of an actual blog object allows us to make extra assertions about how the mock was used.

    For example, a mock allows us to test how many times it was called, the arguments it was called with and even whether the mock was called at all. We’ll see additional examples in the next section.

    Other Assertions We Can Make on Mocks

    Using the previous example, we can make some more useful assertions on our Mock blog object.

    import main
    
    from unittest import TestCase
    from unittest.mock import patch
    
    
    class TestBlog(TestCase):
        @patch('main.Blog')
        def test_blog_posts(self, MockBlog):
            blog = MockBlog()
    
            blog.posts.return_value = [
                {
                    'userId': 1,
                    'id': 1,
                    'title': 'Test Title',
                    'body': 'Far out in the uncharted backwaters of the unfashionable  end  of the  western  spiral  arm  of  the Galaxy\ lies a small unregarded yellow sun.'
                }
            ]
    
            response = blog.posts()
            self.assertIsNotNone(response)
            self.assertIsInstance(response[0], dict)
    
            # Additional assertions
            assert MockBlog is main.Blog # The mock is equivalent to the original
    
            assert MockBlog.called # The mock wasP called
    
            blog.posts.assert_called_with() # We called the posts method with no arguments
    
            blog.posts.assert_called_once_with() # We called the posts method once with no arguments
    
            # blog.posts.assert_called_with(1, 2, 3) - This assertion is False and will fail since we called blog.posts with no arguments
    
            blog.reset_mock() # Reset the mock object
            
            blog.posts.assert_not_called() # After resetting, posts has not been called.

    As stated earlier, the mock object allows us to test how it was used by checking the way it was called and which arguments were passed, not just the return value.

    Mock objects can also be reset to a pristine state i.e. the mock object has not been called yet. This is especially useful when you want to make multiple calls to your mock and want each one to run on a fresh instance of the mock.

    Side Effects

    These are the things that you want to happen when your mock function is called. Common examples are calling another function or raising exceptions.

    Let us revisit our sum function. What if, instead of hard coding a return value, we wanted to run a custom sum function instead? Our custom function will mock out the undesired long running time.sleep call and only remain with the actual summing functionality we want to test. We can simply define a side_effect in our test.

    from unittest import TestCase
    from unittest.mock import patch
    
    def mock_sum(a, b):
        # mock sum function without the long running time.sleep
        return a + b
    
    class TestCalculator(TestCase):
        @patch('main.Calculator.sum', side_effect=mock_sum)
        def test_sum(self, sum):
            self.assertEqual(sum(2,3), 5)
            self.assertEqual(sum(7,3), 10)

    Running the tests should pass:

    .
    _____________________________________________________________
    
    Ran 1 test in 0.001s
    
    OK

    Continous Integration Using Semaphore CI

    Adding Continous Integration with Semaphore is very easy. Once you have everything committed and pushed to Github or Bitbucket, go here and create a new account or sign into an existing account. We’ll be using a Github repo containing the Blog class example and test.

    From your dashboard, click Add New Project.

    add new

    You will be asked to select either Github or Bitbucket as a source. Pick a source as per your preference.

    add source

    After selecting a source, select the repository.

    select repo

    Next, select the branch to build from.

    select branch

    Semaphore will analyze the project and show you the build settings:

    analysis

    Customize your plan to look as follows:

    build settings

    After that, click Build with these settings at the bottom of that page.

    passed

    Once your build passes, that’s it. You have successfully set up continuous integration on Semaphore CI.

    Conclusion

    In this article, we have gone through the basics of mocking with Python. We have covered using the @patch decorator and also how to use side effects to provide alternative behavior to your mocks. We also covered how to run a build on Semaphore.

    You should now be able to use Python’s inbuilt mocking capabilities to replace parts of your system under test to write better and faster tests.

    For more detailed information, the official docs are a good place to start.

    Please feel free to leave your comments and questions in the comments section below.

    2 thoughts on “Getting Started with Mocking in Python

    1. Why in very first example with return value = 9 test is OK? You’re summing 2 and 3, so the test I guess should fail?

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Amos Omondi
    Writen by: