Django Signals - How to Mute Them in Tests

Django Signals (6 Part Series)

Intro

Django signals provide a powerful way to decouple applications by allowing certain senders to notify a set of receivers when actions occur. However, when writing tests, these signals can sometimes get in the way, making our tests slower and more complex. In this guide, we’ll explore how to effectively mute Django signals in your test suite.

Understanding Django Signals

Django signals allow you to execute code when certain actions occur in your models. Common signals include:

pre_save: Called before a model’s save() method
post_save: Called after a model’s save() method
pre_delete: Called before a model instance is deleted
post_delete: Called after a model instance is deleted
m2m_changed: Called when a many-to-many relationship changes

Why Mute Signals in Tests

There are several compelling reasons to mute signals in your tests:

Improved Test Performance: Signals can trigger additional database operations or external service calls, slowing down your tests.
Isolation: You want to test specific functionality without side effects from signals.
Predictability: Signals might cause unexpected state changes that make tests harder to reason about.

Implementation Guide

Let’s implement a robust signal muting solution using pytest fixtures.

import pytest
from django.db.models import signals


@pytest.fixture
def mute_signals():
    """Fixture to temporarily mute Django model signals."""
    _signals = [
        signals.pre_save,
        signals.post_save,
        signals.pre_delete,
        signals.post_delete,
        signals.m2m_changed,
    ]
    restore = {}
    for signal in _signals:
        # Temporarily remove the signal's receivers
        restore[signal] = signal.receivers
        signal.receivers = []

    def restore_signals():
        # Restore the signals after the test
        for signal, receivers in restore.items():
            signal.receivers = receivers

    # Add the restore function as a finalizer
    pytest.request.addfinalizer(restore_signals)

Credit to factoryboy’s mute_signal.

Using the Fixture in Tests

Here’s how to use our muting fixture with model_bakery:

import pytest
from model_bakery import baker


pytestmark = pytest.mark.django_db


def test_user_creation_without_signals(mute_signals):
    # This won't trigger any signals
    user = baker.make("auth.User")
    assert user.pk is not None


# All tests in this class will have signals muted
@pytest.mark.usefixtures("mute_signals")
class TestUserModel:
    def test_user_profile_creation(self):
        user = baker.make("auth.User")
        # Test without signal interference

Examples

Let’s look at some practical examples where muting signals is particularly useful.

Example 1: Testing User Registration

import pytest
from django.contrib.auth.models import User

from some_app.models import UserProfile


@pytest.mark.django_db
def test_user_registration_logic(mute_signals):
    # Normally, a post_save signal might create a UserProfile
    # With signals muted, we can test the core registration logic
    user = baker.make(User)
    
    # No UserProfile should be created because signals are muted
    assert not UserProfile.objects.filter(user=user).exists()

Example 2: Testing M2M Relationships

import pytest

from some_app.models import Project, Developer


@pytest.mark.django_db
def test_project_developer_assignment(mute_signals):
    project = baker.make(Project)
    developers = baker.make(Developer, _quantity=3)
    
    # Add developers to project without triggering m2m_changed signals
    project.developers.add(*developers)
    
    assert project.developers.count() == 3

Conclusion

Muting Django signals in tests is a useful technique that can help create more reliable and faster tests. By using the fixtures and patterns described in this guide, you can effectively manage signal behavior in your test suite while maintaining test clarity and reliability.

All done!