测试django

by Haki Benita

通过Haki Benita

如何像专业人士一样测试Django Signals (How to test Django Signals like a pro)

For a better reading experience, check out this article on my website.

为了获得更好的阅读体验，请在我的网站上查看此文章 。

Django Signals are extremely useful for decoupling modules. They allow a low-level Django app to send events for other apps to handle without creating a direct dependency.

Django Signals对于解耦模块非常有用。 它们允许低级Django应用程序发送事件供其他应用程序处理，而无需创建直接依赖项。

Signals are easy to set up, but harder to test. So In this article, I’m going to walk you through implementing a context manager for testing Django signals, step by step.

信号易于设置，但较难测试。 因此，在本文中，我将逐步指导您实现用于测试Django信号的上下文管理器。

用例 (The Use Case)

Let’s say you have a payment module with a charge function. (I write a lot about payments, so I know this use case well.) Once a charge is made, you want to increment a total charges counter.

假设您有一个带有收费功能的付款模块。 (我写了很多有关付款的书 ，所以我很好地了解了这个用例。)收费后，您想增加总收费计数器。

What would that look like using signals?

使用信号会是什么样？

First, define the signal:

首先，定义信号：

# signals.py

from django.dispatch import Signal

charge_completed = Signal(providing_args=['total'])

Then send the signal when a charge completes successfully:

然后在充电成功完成后发送信号：

# payment.py

from .signals import charge_completed

@classmethoddef process_charge(cls, total):

# Process charge…

if success:        charge_completed.send_robust(            sender=cls,            total=total,        )

A different app, such as a summary app, can connect a handler that increments a total charges counter:

另一个应用程序(例如摘要应用程序)可以连接一个使总费用计数器递增的处理程序：

# summary.py

from django.dispatch import receiver

from .signals import charge_completed

@receiver(charge_completed)def increment_total_charges(sender, total, **kwargs):    total_charges += total

The payment module does not have to know the summary module or any other module handling completed charges. You can add many receivers without modifying the payment module.

支付模块不必知道汇总模块或处理已完成费用的任何其他模块。 您可以添加许多收款人，而无需修改付款模块 。

For example, the following are good candidates for receivers:

例如，以下是适合接收者的候选者：

• Update the transaction status.
  更新交易状态。
• Send an email notification to the user.
  向用户发送电子邮件通知。
• Update the last used date of the credit card.
  更新信用卡的最后使用日期。

测试信号 (Testing Signals)

Now that you got the basics covered, let’s write a test for process_charge. You want to make sure the signal is sent with the right arguments when a charge completes successfully.

现在，您已经了解了基础知识，让我们为process_charge编写一个测试。 您要确保在成功完成充电后以正确的参数发送信号。

The best way to test if a signal was sent is to connect to it:

测试是否已发送信号的最佳方法是连接到该信号：

# test.py

from django.test import TestCase

from .payment import chargefrom .signals import charge_completed

class TestCharge(TestCase):

def test_should_send_signal_when_charge_succeeds(self):        self.signal_was_called = False        self.total = None

def handler(sender, total, **kwargs):            self.signal_was_called = True            self.total = total

charge_completed.connect(handler)

charge(100)

self.assertTrue(self.signal_was_called)        self.assertEqual(self.total, 100)

charge_completed.disconnect(handler)

We create a handler, connect to the signal, execute the function and check the args.

我们创建一个处理程序，连接到信号，执行功能并检查参数。

We use self inside the handler to create a closure. If we hadn’t used self the handler function would update the variables in its local scope and we won’t have access to them. We will revisit this later.

我们在处理程序中使用self来创建一个闭包。 如果我们不使用self则处理函数将在其本地范围内更新变量，而我们将无法访问它们。 我们稍后会再次讨论。

Let’s add a test to make sure the signal is not called if the charge failed:

让我们添加一个测试， 以确保如果充电失败，则不会调用该信号 ：

def test_should_not_send_signal_when_charge_failed(self):    self.signal_was_called = False

def handler(sender, total, **kwargs):        self.signal_was_called = True

charge_completed.connect(handler)

charge(-1)

self.assertFalse(self.signal_was_called)

charge_completed.disconnect(handler)

This is working but it’s a lot of boilerplate! There must be a better way.

这是可行的，但是很多样板！ 肯定有更好的办法。

输入上下文管理器 (Enter Context Manager)

Let’s break down what we did so far:

让我们分解一下到目前为止我们所做的：

1. Connect a signal to some handler.
   将信号连接到某个处理程序。
2. Run the test code and save the arguments passed to the handler.
   运行测试代码并保存传递给处理程序的参数。
3. Disconnect the handler from the signal.
   断开处理程序与信号的连接。

This pattern sounds familiar…

这种模式听起来很熟悉...

Let’s look at what a (file) open context manager does:

让我们看一下(文件) 开放上下文管理器的作用：

1. Open a file.
   打开一个文件。
2. Process the file.
   处理文件。
3. Close the file.
   关闭文件。

And a database transaction context manager:

和数据库事务上下文管理器 ：

1. Open transaction.
   公开交易。
2. Execute some operations.
   执行一些操作。
3. Close transaction (commit / rollback).
   关闭交易(提交/回滚)。

It looks like a context manager can work for signals as well.

似乎上下文管理器也可以处理信号 。

Before you start, think how you want to use a context manager to test signals:

在开始之前，请考虑如何使用上下文管理器测试信号：

with CatchSignal(charge_completed) as signal_args:    charge(100)

self.assertEqual(signal_args.total, 100)

Nice, let’s give it a try:

好的，让我们尝试一下：

class CatchSignal:    def __init__(self, signal):        self.signal = signal        self.signal_kwargs = {}

def handler(sender, **kwargs):            self.signal_kwrags.update(kwargs)

self.handler = handler

def __enter__(self):        self.signal.connect(self.handler)        return self.signal_kwrags

def __exit__(self, exc_type, exc_value, tb):        self.signal.disconnect(self.handler)

What we have here:

我们在这里拥有什么：

• You initialized the context with the signal you want to “catch”.
  您使用要“捕获”的信号初始化了上下文。
• The context creates a handler function to save the arguments sent by the signal.
  上下文创建一个处理函数，以保存信号发送的参数。

• You create closure by updating an existing object (signal_kwargs) on self.

  您可以通过更新现有的对象(创建封闭signal_kwargs上) self 。

• You connect the handler to the signal.
  您将处理程序连接到信号。

• Some processing is done (by the test) between __enter__ and __exit__.

  (通过测试)在__enter__和__exit__之间进行了一些处理。

• You disconnect the handler from the signal.
  您从信号断开处理程序。

Let’s use the context manager to test the charge function:

让我们使用上下文管理器测试计费功能：

def test_should_send_signal_when_charge_succeeds(self):    with CatchSignal(charge_completed) as signal_args:        charge(100)    self.assertEqual(signal_args[‘total’], 100)

This is better, but how would the negative test look like?

这样比较好，但是负面测试会是什么样子？

def test_should_not_send_signal_when_charge_failed(self):    with CatchSignal(signal) as signal_args:        charge(100)    self.assertEqual(signal_args, {})

Yak, that’s bad.

k牛，不好。

Let’s take another look at the handler:

让我们再看一下处理程序：

• We want to make sure the handler function was invoked.
  我们要确保处理程序函数被调用。
• We want to test the args sent to the handler function.
  我们要测试发送到处理程序函数的参数。

Wait… I already know this function!

等等... 我已经知道这个功能了！

输入模拟 (Enter Mock)

Let’s replace our handler with a Mock:

让我们用Mock替换处理程序：

from unittest import mock

class CatchSignal:    def __init__(self, signal):        self.signal = signal        self.handler = mock.Mock()

def __enter__(self):        self.signal.connect(self.handler)        return self.handler

def __exit__(self, exc_type, exc_value, tb):        self.signal.disconnect(self.handler)

And the tests:

和测试：

def test_should_send_signal_when_charge_succeeds(self):    with CatchSignal(charge_completed) as handler:        charge(100)    handler.assert_called_once_with(        total=100,        sender=mock.ANY,        signal=charge_completed,    )

def test_should_not_send_signal_when_charge_failed(self):    with CatchSignal(charge_completed) as handler:        charge(-1)        handler.assert_not_called()

Much better!

好多了！

You used the mock for exactly what it should be used for, and you don’t need to worry about scope and closure.

您使用了该模拟程序来确定它的确切用途，而不必担心范围和闭包。

Now that you have this working, can you make it even better?

现在您已经可以使用它了 ， 您可以使其变得更好吗？

输入contextlib (Enter contextlib)

Python has a utility module for handling context managers called contextlib.

Python有一个用于处理上下文管理器的实用程序模块，称为contextlib 。

Let’s rewrite our context using contextlib:

让我们使用contextlib重写contextlib ：

from unittest import mockfrom contextlib import contextmanager

@contextmanagerdef catch_signal(signal):    """Catch django signal and return the mocked call."""    handler = mock.Mock()    signal.connect(handler)    yield handler    signal.disconnect(handler)

I like this approach better because it’s easier to follow:

我更喜欢这种方法，因为它更容易遵循：

• The yield makes it clear where the test code is executed.
  收益率清楚地表明了在哪里执行测试代码。

• No need to save objects on self because the setup code (enter and exit) are in the same scope.

  因为设置代码(输入和退出)在同一范围内，所以无需self保存对象。

And that’s it — 4 lines of code to rule them all! Profit!

就是这样-4行代码来统治它们！ 利润！

翻译自: https://www.freecodecamp.org/news/how-to-testing-django-signals-like-a-pro-c7ed74279311/

测试django