Isolating Dependencies with Test Doubles: Stubs

Introduction and Context Setting

Welcome to the second lesson in our exploration of Test Driven Development (TDD) with Python and Pytest . Previously, you learned about using dummies to isolate dependencies. In this lesson, we'll focus on another type of test double — stubs . By the end of this lesson, you'll understand what stubs are and how to implement them in your tests, specifically for isolating dependencies like external services.

Understanding Stubs in Testing

Test doubles help us isolate parts of our application for testing. We've previously discussed dummies; now, let's move to a slightly more useful test double: stubs . Stubs are predefined answers to method calls made during testing. They don't track how they're used, unlike more complex test doubles that we'll learn about later. Stubs are beneficial when you're testing a function that relies on an external service or complex dependency. They let you simulate the function's output, making your tests faster and more predictable. Keep in mind, though, that stubs primarily ensure your application logic functions as intended and don't necessarily verify the correctness of external dependencies. Stubs are used to provide consistent, predefined responses to specific method calls in tests, allowing you to control the behavior of certain dependencies without implementing their actual functionality. Unlike dummies, which are mere placeholders, stubs actively simulate responses, making them useful when you need predictable outcomes from dependencies. This predictability allows you to isolate and test your application's logic without needing to rely on the behavior of external systems, which is especially helpful when those systems may be complex or introduce variability.

Example: Crafting a Weather Alert Service using Stubs

Let’s apply the TDD workflow to build a WeatherAlertService using stubs.

Getting Ready to Test

We are building a Weather Alert Service that will get its data from a WeatherService, which receives weather data and issues alerts based on certain conditions. The WeatherAlertService will need to fetch data from an external data source, which is not feasible in a testing environment. For the tests that rely on data from the WeatherService, we can define what the WeatherData looks like. The classes are structured as follows: Python class WeatherData: def __init__(self, temperature: float, conditions: str): self.temperature = temperature self.conditions = conditions

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Red: Writing the First Test

Create a test file named test_weather_alert_service.py with the following test cases:

Python

import pytest
from weather_alert_service import WeatherAlertService, WeatherData


class WeatherServiceStub:
    def __init__(self):
        self.temperature = 20
        self.conditions = "sunny"

    # Not part of the interface. Used in testing to stub out the results
    # of get_current_weather
    def set_weather(self, temperature, conditions):
        self.temperature = temperature
        self.conditions = conditions

    def get_current_weather(self, _location):
        return WeatherData(self.temperature, self.conditions)


class TestWeatherAlert:
    @pytest.fixture
    def setup_test(self):
        weather_service_stub = WeatherServiceStub()
        return weather_service_stub, WeatherAlertService(weather_service_stub)
    
    def test_should_return_heat_warning_when_temperature_is_above_35(
        self,
        setup_test,
    ):
        # Arrange
        weather_service, alert_service = setup_test
        weather_service.set_weather(36, "sunny")

        # Act
        alert = alert_service.should_send_alert("London")

        # Assert
        assert alert == "Extreme heat warning. Stay hydrated!"

import pytest
from weather_alert_service import WeatherAlertService, WeatherData


class WeatherServiceStub:
    def __init__(self):
        self.temperature = 20
        self.conditions = "sunny"

    # Not part of the interface. Used in testing to stub out the results
    # of get_current_weather
    def set_weather(self, temperature, conditions):
        self.temperature = temperature
        self.conditions = conditions

    def get_current_weather(self, _location):
        return WeatherData(self.temperature, self.conditions)


class TestWeatherAlert:
    @pytest.fixture
    def setup_test(self):
        weather_service_stub = WeatherServiceStub()
        return weather_service_stub, WeatherAlertService(weather_service_stub)
    
    def test_should_return_heat_warning_when_temperature_is_above_35(
        self,
        setup_test,
    ):
        # Arrange
        weather_service, alert_service = setup_test
        weather_service.set_weather(36, "sunny")

        # Act
        alert = alert_service.should_send_alert("London")

        # Assert
        assert alert == "Extreme heat warning. Stay hydrated!"

Here:

We implement a stub, WeatherServiceStub, to simulate weather data. We add the set_weather method, which allows tests to pre-define the results from the service.
We write our first Pytest test to check if WeatherAlertService processes weather data correctly.

Run this test, and expect it to fail initially as WeatherAlertService is not yet implemented to handle the specified conditions.

Refactor: Introducing Automatic Stubs with Pytest Mocks

In the initial implementation, we created a manual stub, WeatherServiceStub, to simulate weather data. Now, we will refactor this by leveraging the pytest-mock library to streamline the process and improve maintainability. Using pytest-mock, we can create flexible and reusable stubs with minimal code.

The pytest-mock library allows us to set up method expectations and return values dynamically. By substituting our hand-crafted stub with a pytest-mock-based one, we achieve the same test outcomes but with enhanced clarity and simplicity. This approach decreases the potential for bugs and makes adjusting test parameters easier.

Here's how we refactor our TestWeatherAlert:

Remove the WeatherServiceStub completely.
Inject the mocker into the setup_test() function and set the weather_service_stub to be mocker.Mock()
Through pytest-mock, we eliminate the need to manage state explicitly within our custom stub class.

The refactored test class using the pytest-mock library is shown below: