首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何断言一个猴子补丁在pytest中被调用了?

在pytest中,可以使用monkeypatch来断言一个猴子补丁是否被调用。猴子补丁是一种在运行时修改或替换代码的技术,通常用于在测试中模拟或修改函数的行为。

要断言一个猴子补丁在pytest中被调用了,可以按照以下步骤进行操作:

  1. 导入pytest和monkeypatch模块:
代码语言:txt
复制
import pytest
from _pytest.monkeypatch import MonkeyPatch
  1. 创建一个monkeypatch对象:
代码语言:txt
复制
@pytest.fixture
def monkeypatch():
    mpatch = MonkeyPatch()
    yield mpatch
    mpatch.undo()

这里使用pytest的fixture装饰器来创建一个名为monkeypatch的fixture,它返回一个MonkeyPatch对象。使用yield语句来在测试结束后自动执行undo()方法,以确保猴子补丁的修改被撤销。

  1. 使用monkeypatch.setattr()方法来修改函数的行为:
代码语言:txt
复制
def test_my_function(monkeypatch):
    def mock_function():
        # 模拟函数的行为
        pass

    monkeypatch.setattr('package.module.my_function', mock_function)

    # 调用被修改的函数
    package.module.my_function()

    # 断言猴子补丁被调用
    assert monkeypatch.setattr.called_once_with('package.module.my_function', mock_function)

在测试函数中,首先定义一个mock_function来模拟被修改函数的行为。然后使用monkeypatch.setattr()方法来将被修改函数替换为mock_function。最后,通过assert语句来断言monkeypatch.setattr()方法被调用,并传入正确的参数。

这样,当运行pytest测试时,如果猴子补丁在被调用的地方生效,断言将会通过,否则将会失败。

需要注意的是,以上示例中的'package.module.my_function'是一个示意的函数路径,实际使用时需要替换为被修改函数的准确路径。

推荐的腾讯云相关产品:腾讯云函数(Serverless Cloud Function)

  • 产品介绍链接地址:https://cloud.tencent.com/product/scf
页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 接口自动化框架设计漫谈V1.0

    你好,我是刚哥。 针对“pytest搭建接口自动化框架”,谈谈对框架设计的当前认知。 简约至上。选择pytest就是选择Python,Python的设计理念是Simple is better than complex,不能让初学者直接上手的框架设计,都是在反其道而行之。所谓具备编程思想的自动化框架,并不值得追求。 原生用法。Beautiful is better than ugly,能不封装就不封装,不改变依赖库的函数声明,函数名、入参列表、返回类型。通过可省参数追加入参,通过装饰器添加代码,通过猴子补丁更改行为。 数据用例一体。Flat is better than nested,平铺比嵌套更容易编写,阅读,维护。将数据放在用例文件中,在单个文件中编写用例。数据驱动时,可从外部读取。变量管理亦是如此。 pytest提供了测试框架的基础骨架,Python库提供了各式各样的组装零件,我们要做的是拼凑,搭建适用于接口自动化测试的框架。 宜轻不宜重。挑选Python库,优先选择轻量级的,比如pytest-html既能满足使用需要,又能定制化样式,就不用安装依赖Java环境的Allure。比如Python内置logging就能打印日志,就没必要非得使用依赖visual c++的loguru。 用例独立。用例相互之间没有依赖,随便拉出一条用例就能执行。多接口场景用例,把每个接口视为一个测试步骤,排列在用例里面。无上游依赖、出参稳定的接口抽取为公共函数。简单来说,用例可以只包含一个接口,也可以包含多个接口。接口可以写在用例里面,也可以写在用例外面作为公共函数,再导入到用例里面。接口参数不同验证不同场景,复制用例文件,命名为新用例。 中文命名。用代码编写pytest,有个缺点是文件命名晦涩难懂。在“用例独立”这条设计原则之上,可以采用中文命名用例集(文件夹)和用例名称(文件名)。不存在用例相互依赖,就不需要import,代码中就不会出现中文,不影响代码执行和“专业性”。用中文写注释没问题,不要用中文作为对象名。 标记不如目录。pytest支持marker给测试用例打标,执行时按标记筛选用例执行。用例多了以后,维护标记变得麻烦。将用例集按照某种特性分组,比如基础自动化用例集、每日巡检用例集、联调用例集。按目录维护用例,按目录批量执行用例。

    01

    tep1.0.0正式版发布且将不再维护

    根据pypistats统计,tep在pypi的下载量达到了1w,对于纯个人研发的一款测试小工具来说,已经算不错了,要知道HttpRunner也才6w啊。tep可以说是我在接口自动化测试这个领域的技术沉淀,凝结了个人经验和所见所闻的精华之作,它基于Pytest,借鉴了JMeter、RobotFramework、HttpRunner、京东接口测试平台等各种优秀自动化设计思想,小小工具,蕴含大大能量。相信它也已经影响了不少人,让初学者知道Pytest该怎么玩,让入门者知道Pytest工程化是什么样子,让熟练者可以参考对照优化代码。然而当我把tep优化到1.0.0正式版以后,为什么却选择停止维护呢? 一、 小工具的表达力不够。当我试图用tep来描绘更多自动化设计思想时,瞬间感觉到了一丝苍白,我不一定讲的清楚,别人也不一定能够理解,用代码来交流始终存在着一定门槛。二、每个人对Pytest使用方式不同 。Pytest本身是测试框架,很多人用它来做二次开发,设计”测试框架“,有好的,有差的,不管白猫黑猫能逮到耗子就是好猫,不管设计的如何,能实现接口自动化项目落地就是好框架。tep要想在这个方向上,建立一套标准,几乎是不可能的。这不并意味我会就此放弃Pytest,相反,我将致力于Pytest平台化,从做小工具改为做测试平台。 测试平台具有非常直观的强大表现力,并且具有工程化的规范性,一看就懂,一用就会,一点就通。测试平台也是能更好的做技术沉淀的,如果说写小工具是玩玩而已,那么开发测试平台就是认真搞技术了。比如,如何提高Pytest并行执行的效率,我相信测试平台会比小工具,更能给出一个比较完整的解决方案。下次使用Pytest,也许就不是从tep startproject开始了,而是docker run。

    01
    领券