pytest:为每个测试函数设置一个模拟

Man*_*anu 1 python unit-testing mocking pytest python-unittest

为 python 项目创建单元测试,我们正在达到这种“模板”

from unittest import TestCase
from unittest.mock import patch, Mock

@patch('......dependency1')
@patch('......dependency2')
@patch('......dependencyn')
class MyTest(TestCase):

  def test_1(self, mock1, mock2, mockn):
      # setup mock1 & mock2...
      # call the subject case 1
      # assert response and/or interactions with mock1 and mock2...

  def test_2(self, mock1, mock2, mockn):
      # setup mock1 & mock2...
      # call the subject case 2
      # assert response and/or interactions with mock1 and mock2...
Run Code Online (Sandbox Code Playgroud)

关键是,有时“设置”部分在某些测试用例中是重复的,因此我想将配置提取到方法中setUp(),例如,以下是伪代码:

def setUp(self):
  mock1.foo.return_value = 'xxx'
  mock2.goo.side_effect = [ ... ]

def test_1(self, mock1, mock2, mockn):
  # default setup is perfect for this test

def test_2(self, mock1, mock2, mockn):
  # this time I need...
  mock2.goo.side_effect = [ ... ]
Run Code Online (Sandbox Code Playgroud)

这个想法有可能实现吗?

Dir*_*ann 5

两者pytestunittest提供了您所询问的可能性,并且这两种功能都在各自的文档中通过示例进行了解释:fixturepytest文档和setup文档中查找unittest

然而,这些功能在实践中的使用很快就会失控,并且有可能创建不可读的测试代码。它有两种形式,一种是共享夹具设置变得太大(太笼统),使读者很难理解与特定测试用例实际相关的内容。第二个是,测试代码不再是独立的,似乎魔法发生在外部。梅萨罗斯将由此产生的测试气味称为“模糊测试”,上述场景称为“常规装置”和“神秘客人”。

我的建议是,更喜欢从每个测试中显式调用的辅助函数/方法。您可以拥有其中几个,给它们提供描述性名称,从而保持测试代码的可读性,而不需要读者首先搜索文件以查找任何“automagic”内容。在您的示例中,测试可能如下所示:

def test_1(self, mock1, mock2, mockn):
  default_setup(mock1, mock2, mockn)
  # further test code...

def test_2(self, mock1, mock2, mockn):
  default_setup(mock1, mock2, mockn)
  setup_mock2_to_behave_as_xxx(mock2)
  # further test code...

def test_3(self, mock1, mock2, mockn):
  setup_mock1_to_always_xxx(mock1)
  setup_mock2_to_behave_as_xxx(mock2)
  setup_mockn_to_xxx(mockn)
  # further test code...
Run Code Online (Sandbox Code Playgroud)