【问题标题】:Python patch decorator spilling into other methodsPython补丁装饰器溢出到其他方法中
【发布时间】:2014-12-13 11:15:32
【问题描述】:

我的理解是,当您在单元测试中使用补丁装饰器时(我正在使用鼻子框架),该补丁装饰器的范围就是测试用例的范围。问题来了:

@patch('a')
@patch('b')
@patch('b')
def test_add_stuff(self, mock_a, mock_b, mock_c):
    url = '/path/blah/blah'
    assert_true(stuff)
    # Now those three patch decorators should be "done"


def test_delete_stuff(self):
    url = '/another_path/not_important'
    assert_true(something)

在我的第二个测试用例 test_delete_stuff 中,我在实际代码中添加了一个打印语句,以调试抛出的错误。事实证明,通过 url 命中的控制器操作中的函数调用之一是返回一个 MagicMock 对象!它是上一个测试用例中的 mock_b。

如果我只是颠倒两个测试用例的顺序,没有任何变化。如果我用补丁装饰器注释掉那个,我的第二个测试用例就通过了。

附加信息: 这些实例方法所在的类上没有补丁装饰器。

有什么想法吗?

--更新--

事实证明,我没有模拟我的函数调用 from where they were being looked up,这解决了问题。但是,它并没有解释为什么补丁的范围超过了一个测试用例。

如果控制器仅在使用 app.get 发送 GET 请求时才被实例化,并且控制器文件中的导入被模拟,为什么 MagicMock 对象会在多个单元测试中持续存在?

【问题讨论】:

  • 如果能把所有代码都展示出来就更好了。确实感觉嘲笑的一些全球性副作用会持续存在。
  • 一些缓存或单例...
  • @JanusTroelsen 你能用重现问题所需的最短代码改进问题吗?

标签: python unit-testing mocking nose


【解决方案1】:

我猜路径范围的问题已经出现,因为您修补了 TestCase 类中的方法。你可以在the official Python unittest.patch documentation找到:

Patch 可以用作 TestCase 类的装饰器。它通过装饰类中的每个测试方法来工作。当您的测试方法共享一个公共补丁集时,这会减少样板代码。 patch() 通过查找以 patch.TEST_PREFIX 开头的方法名称来查找测试。默认情况下,这是“测试”,它与 unittest 查找测试的方式相匹配。您可以通过设置 patch.TEST_PREFIX 来指定替代前缀。

所以所有前缀为test 的方法都将使用补丁进行修饰。这是默认行为。

【讨论】:

  • Bowser 将其用作方法装饰器,而不是类装饰器。
  • 他其实是在使用一个类,因为问题中有一句话:>附加信息:这些实例方法所在的类上没有补丁装饰器。
  • 没错。这明确表示他们没有使用补丁装饰器作为类装饰器。
猜你喜欢
  • 2017-01-31
  • 1970-01-01
  • 2022-12-09
  • 2020-02-10
  • 2021-07-19
  • 2021-12-20
  • 1970-01-01
  • 2021-11-21
  • 2020-12-03
相关资源
最近更新 更多