聊到Python测试框架pytest几乎是绕不开的那个名字。很多项目从unittest迁移到pytest之后最直观的感受就是代码量下降了测试的可读性和效率明显提升。但大多数团队只用了它基础的assert和fixture功能真正让它拉开差距的高级用法——比如动态参数化、猴子补丁、异步测试、插件协同——反而用得很少。这篇博文我想从自己实际项目的经验出发把pytest里那些“高级但日常用得上”的测试技术拆开讲透包括fixture的作用域设计、mock外部依赖、异步事件循环的处理、覆盖率与CI集成以及我在真实工程里踩过的坑。无论你是刚开始写测试还是已经写了几年这些内容应该都能让你对pytest有一个更系统的理解。1. 为什么是pytest从unittest到pytest的工程化演进1.1 断言风格与failure输出的差异先从一个最容易被忽略的差异说起断言。Python原生的assert在unittest里基本是“能用但不友好”一个断言失败只告诉你AssertionError具体两个值差在哪、哪些部分不匹配要自己加msg或者打印日志才能看出来。pytest重写了断言机制当你写assert user.name admin失败时它会自动展示左右两侧的实际值对于字典、列表这类复杂结构还会用diff的方式标出哪里不一致。这意味着测试代码可以回归到最朴素的写法不用刻意去记assertEqual、assertIn、assertRaises这么一套API。团队新人上手成本也低很多只要会写assert就能写pytest用例。我见过不少项目从unittest迁移过来单是把断言从self.assertEqual改成assert这一点就删掉了大量样板代码而测试意图反而更清晰了。1.2 fixture机制解决了什么问题fixture大概是pytest和unittest最大的分水岭。unittest里每个测试类靠setUp和tearDown准备和清理环境一旦用例之间的公共数据变多就得继承一个又一个BaseTestCase或者写一堆工具函数在类内部调用。pytest的fixture则是声明式的依赖注入测试函数声明需要什么参数pytest就去查找和创建对应的fixture。这种设计让“准备环境”和“测试逻辑”彻底解耦。比如你要测数据库操作可以定义一个db_sessionfixture负责建连和销毁测试函数只需要参数里写db_sessionpytest会自动传入。更关键的是fixture可以跨文件复用不需要继承任何基类。你的用例是函数、类、还是模块fixture都能覆盖粒度由你决定。这让测试代码变成了一组可以自由组合的积木而不是一棵强制继承的树。1.3 插件生态与conftest的作用pytest的定位从来不是一个孤立的框架而是一个插件平台。官方维护的插件加上社区贡献的插件几乎覆盖了测试周期的每个环节覆盖率有pytest-cov重试有pytest-rerunfailures超时控制有pytest-timeout异步支持有pytest-asyncio还有各种报告格式、mock集成、Django/Flask/SQLAlchemy的适配插件。插件的加载入口通常放在conftest.py这个文件是pytest的“局部配置中心”。它不需要被importpytest会自动发现它并且它的作用域只覆盖当前目录及子目录。你可以把fixture、钩子函数、命令行选项都定义在这里。合理拆分conftest.py能让你项目的测试基础设施变得非常干净根目录放全局的fixture每个模块目录放自己领域的fixture互不干扰。2. 高级fixture作用域、工厂模式和依赖注入2.1 fixture作用域与自动使用fixture的scope参数决定了它什么时候创建、什么时候销毁。默认是function也就是每个测试函数都重新执行一次可选值还有class、module、package和session。作用域越大重复执行的成本越低但也要承担状态泄漏的风险。举个例子一个建立数据库连接的操作如果设计成function作用域几百条用例就会建立几百次连接慢到让人怀疑人生。把它改成session作用域整个测试进程只用一次性能提升非常明显。但你要想清楚这个连接是否允许被多个测试用例共享以及是否需要在每个用例之间重置状态。我自己的经验是无状态或者只读的依赖用session或module有状态且用例会修改状态的依赖老老实实用function。autouse参数的意思是“自动使用”不需要测试函数主动声明参数。比如你希望每个用例执行前都清空某个临时目录就可以定义一个autouseTrue的fixture。但autouse一定要慎用尤其在外部依赖上因为它在测试文件里是隐形的别人看用例时很难发现这个副作用存在。2.2 通过yield实现setup/teardownfixture里在yield之前的代码相当于setupyield之后的代码相当于teardown。这个语法比unittest的setUp/tearDown更贴合实际场景因为一个fixture可以同时负责准备和清理而且清理阶段即使测试抛异常也会执行。一个典型的场景是文件系统临时目录import pytest import tempfile import os pytest.fixture def tmp_project(): with tempfile.TemporaryDirectory() as td: os.makedirs(os.path.join(td, src)) yield td测试函数拿到的是tmp_project路径测试结束之后不管断言是否失败TemporaryDirectory都会自动清理掉。这种“上下文管理器风格”的fixture特别适合托管资源数据库连接、文件句柄、网络监听端口、浏览器实例都可以在yield前后做准备和回收。另外要留意的坑是如果yield之前就抛异常了那么yield后面的清理代码不会执行而pytest会标记这个fixture为error。所以如果setup阶段本身就可能失败你需要在fixture内部用try/finally来兜底确保部分创建的资源也能被释放。2.3 工厂模式与request参数有时候一个fixture不能只返回一个固定对象它需要根据测试用例的不同输入创建不同的数据。比如你要测试创建用户的接口不同用例需要不同角色的用户。这时可以把fixture设计成“工厂”fixture本身返回一个函数测试用例调用这个函数并传入参数。pytest.fixture def make_user(db_session): counter 0 def _make_user(usernameNone, roleviewer): nonlocal counter counter 1 username username or fuser_{counter} user User(usernameusername, rolerole) db_session.add(user) db_session.commit() return user return _make_user然后测试里这样用def test_admin_can_delete(make_user): admin make_user(roleadmin) # ...需要说明的是工厂里面捕获了一个counter变量每次调用生成唯一用户名。这种闭包设计在简单的fixture 参数不能满足时非常实用。配合request参数你还可以在工厂内部拿到当前测试节点的信息比如request.node.name用来生成与用例名相关的测试数据。2.4 动态参数化fixture普通参数化是把参数列表写在pytest.mark.parametrize上但如果参数依赖fixture的返回值或者参数集合需要根据某个文件、数据库动态生成就要靠pytest_generate_tests钩子或request.getfixturevalue了。我常用的一种模式是“fixture间接参数化”pytest.fixture def api_client(request): env request.param return APIClient(base_urlenv[base_url], tokenenv[token]) pytest.mark.parametrize( api_client, [ {base_url: https://staging.example.com, token: staging-token}, {base_url: https://prod.example.com, token: prod-token}, ], indirectTrue, ) def test_login(api_client): resp api_client.post(/login, json{username: admin}) assert resp.status_code 200indirectTrue告诉pytest参数名对应的不是普通参数而是一个fixturepytest会把参数值作为request.param传给fixture。这样你就可以针对不同环境、不同配置重复执行同一组用例而测试函数本身完全不需要改。这是数据驱动测试里强烈推荐的手法。3. 参数化与自定义标记数据驱动测试的正确姿势3.1 parametrize参数组合pytest.mark.parametrize是pytest最常用的数据驱动工具。它可以同时组合多个参数名也可以多次使用装饰器形成笛卡尔积。举一个实际例子测试一个字符串转换函数你需要覆盖正常输入、空字符串、特殊字符、Unicode字符等。import pytest def parse_csv_line(line): return [x.strip() for x in line.split(,)] pytest.mark.parametrize( raw,expected, [ (a,b,c, [a, b, c]), (a, b, c, [a, b, c]), (, []), (你,好, [你, 好]), (a,,c, [a, , c]), ], ) def test_parse_csv_line(raw, expected): assert parse_csv_line(raw) expected这里有个细节如果其中某个参数在运行时依赖另一个fixture可以只对某几个参数做parametrize另外的参数由fixture注入。pytest会自动把参数化生成的用例id组合成可读的测试节点名称比如test_parse_csv_line[raw0-expected1]。如果你希望id更直观可以用ids参数指定每个参数组合的显示名这对测试报告尤其友好。3.2 自定义mark与条件跳过pytest允许你通过pytest.mark.xxx给用例打标签然后在运行的时候选择或排除这些标签。最常见的做法是区分冒烟测试、接口测试、慢测试pytest.mark.smoke def test_health_check(): ... pytest.mark.slow def test_heavy_calculation(): ...在pytest.ini里注册标记可以避免pytest的警告[pytest] markers smoke: 冒烟测试用例 slow: 运行时间较长的用例 integration: 依赖外部服务的集成测试运行的时候pytest -m smoke and not slow就可以只跑冒烟但排除慢用例。另一个实用场景是条件跳过有些用例只在特定Python版本或特定依赖安装时才有效pytest.mark.skipif正好派上用场。比如pytest.mark.skipif(sys.platform win32, reason该功能仅在Linux下验证) def test_linux_only_feature(): ...要是跳过的原因是在运行时才能确定比如某个外部服务没起来可以在测试里用pytest.skip()主动跳过这样不会把环境缺失误判为测试失败CI上也不会产生红色告警。3.3 pytest_generate_tests钩子内置的parametrize覆盖不了所有场景尤其当你希望参数化信息来自fixture或者外部配置时。这时可以在conftest.py里实现pytest_generate_tests钩子。def pytest_generate_tests(metafunc): if db_url in metafunc.fixturenames: db_urls load_available_database_urls() metafunc.parametrize(db_url, db_urls, indirectTrue)这段代码的意思是如果一个测试函数或fixture需要db_url这个参数pytest就会调用钩子从你的配置源里动态读取数据库列表并生成多个测试实例。相比在测试用例上硬编码参数这种方式让参数来源与测试代码彻底分离新增一个数据库环境不需要改用例代码只需要改配置源。不过钩子函数要小心设计因为它会影响所有测试。最好用fixturenames判断条件避免误伤无关用例。4. 用mock和猴子补丁隔离外部依赖4.1 monkeypatch fixturepytest内置的monkeypatchfixture是轻量级测试替身的首选。它能把某个对象、环境变量、系统路径临时替换掉测试结束后自动还原。它的使用方式非常简单def test_get_user_with_default_role(monkeypatch): def fake_load_config(): return {default_role: editor} monkeypatch.setattr(config.load_config, fake_load_config) assert get_user().role editormonkeypatch.setattr支持字符串形式的点路径也支持直接传对象。我推荐优先用字符串路径因为这样替换的是模块里的引用而不是对象本身的属性更不容易误伤同一对象的其他依赖。对于环境变量的修改用monkeypatch.setenv(DB_HOST, localhost)测试结束后环境变量也能恢复。注意monkeypatch只在当前测试函数生命周期内有效所以非常适合用来覆盖临时行为。它的替代方案是unittest.mock.patch两者并不是完全等价。monkeypatch更简洁也更贴合pytest的风格unittest.mock提供了更丰富的mock对象如assert_called_once_with适合需要断言调用参数和次数的场景。4.2 unittest.mock在pytest中的结合虽然pytest原生支持monkeypatch但当你需要模拟一个复杂的第三方类并验证它的调用顺序时unittest.mock.Mock更顺手。典型场景是测试发送邮件、上传文件、调用支付网关等外部操作。from unittest.mock import Mock, patch def test_send_notification(): with patch(app.services.send_email) as mock_send: mock_send.return_value {status: sent} result notify_user(userexample.com) assert result[status] sent mock_send.assert_called_once_with( touserexample.com, templatewelcome, )在pytest里推荐用monkeypatch来安装Mock对象避免使用with patch出现缩进嵌套def test_send_notification(monkeypatch): mock_send Mock(return_value{status: sent}) monkeypatch.setattr(app.services.send_email, mock_send) result notify_user(userexample.com) mock_send.assert_called_once_with(touserexample.com, templatewelcome)这样测试函数保持扁平结构读起来更清晰。Mock对象还能设置side_effect来模拟异常mock_send.side_effect TimeoutError(smtp timeout)这在测试失败路径时特别有用你可以验证代码是否正确捕获了外部异常并做了降级处理。4.3 模拟外部API的实战案例假设你的服务里有一段代码启动时会向外部接口请求一个Token然后拿着Token下载报表。这个流程在单元测试里肯定不能真连外网所以需要把两层都mock掉。def fetch_report(api_client, report_id): token api_client.get_token() headers {Authorization: fBearer {token}} return api_client.download(f/reports/{report_id}, headersheaders)测试写法def test_fetch_report(monkeypatch): class FakeClient: def __init__(self): self.calls [] def get_token(self): self.calls.append(get_token) return fake-token def download(self, path, headers): self.calls.append((download, path, headers)) return breport-content fake_client FakeClient() result fetch_report(fake_client, rpt_001) assert result breport-content assert fake_client.calls[0] get_token assert fake_client.calls[1][0] download这里没有使用任何Mock库而是直接写了一个有状态的手写替身。对于简单场景手写替身反而比Mock更直观因为调用链一目了然。如果外部依赖接口很复杂再考虑用专门的库如responses或pytest-mock。pytest-mock是一个常用插件它把unittest.mock包装成了mockerfixture用起来更简洁def test_fetch_report_with_mocker(mocker): mocker.patch.object(APIClient, get_token, return_valuefake-token) mocker.patch.object(APIClient, download, return_valuebreport-content) result fetch_report(APIClient(), rpt_001) assert result breport-contentpytest-mock在测试结束后会自动清理mock不需要手动stopall也是我目前在项目里优先采用的方案。5. 异步测试与pytest-asyncio5.1 环境准备与事件循环作用域现在越来越多的代码是async/await写成的pytest默认的事件循环并不支持直接运行异步测试函数。pytest-asyncio插件补上了这个缺口。安装之后你需要给异步测试函数加上标记import pytest pytest.mark.asyncio async def test_async_operation(): result await some_async_function() assert result ok如果不加markpytest会把它当作普通函数执行然后报“coroutine was never awaited”的警告。另一个关键点是事件循环的作用域。pytest-asyncio默认使用function作用域也就是说每个异步测试函数都会创建一个新的事件循环。这个设计有助于隔离但如果你有很多异步fixture频繁创建事件循环会有额外开销。你可以在配置里改成session作用域让所有异步测试共享一个事件循环[pytest] asyncio_mode auto asyncio_default_fixture_loop_scope sessionasyncio_mode auto这个选项很值得推荐它让pytest自动识别async def测试函数并运行不需要手动加pytest.mark.asyncio。不过对于团队协作我建议显式声明因为隐性行为在排查问题时容易让人困惑。5.2 异步fixture与async测试函数异步fixture的写法和普通fixture差不多只是需要把fixture定义成async def并且用yield来做teardownimport pytest pytest.fixture async def async_client(): client await create_http_client() yield client await client.close()注意异步fixture不需要加pytest.mark.asynciopytest-asyncio会自动处理。但如果asyncio_mode strict默认模式测试函数必须显式带markfixture则不受此限制。如果混用同步fixture和异步fixturepytest决定依赖顺序时会根据是否有I/O等待来调度你尽量不要在同步fixture里去调用异步函数否则会卡在事件循环上。实在需要的话可以用asyncio.run()包一层但那样会新建一个独立事件循环要谨慎处理循环之间的资源传递。6. 插件与集成覆盖率、超时、重试和CI6.1 pytest-cov与覆盖率阈值写测试不是为了追求100%覆盖率但没有覆盖率数字团队很容易“自我感动”。pytest-cov可以帮你统计行覆盖率、分支覆盖率并输出到控制台或生成XML/HTML报告。通常配合pytest.ini里的addopts使用[pytest] addopts --covmy_package --cov-reporthtml --cov-reportterm-missing --cov-fail-under80--covmy_package指定统计哪个包--cov-reportterm-missing会在终端列出没有覆盖到的行号--cov-fail-under80表示如果覆盖率低于80%pytest会返回非零退出码CI会失败。这个阈值需要根据项目实际调整太高的阈值会逼着团队写一堆没有测试价值的异常分支太低又起不到保护作用。我的习惯是先让覆盖率工具跑起来看趋势再逐步提高阈值。6.2 pytest-timeout与pytest-rerunfailures超时控制在集成测试里几乎是必需品。pytest-timeout可以给每个测试设置超时时间超时后强制中断避免某个用例挂起导致整个测试套件卡住。pytest --timeout60 --timeout-methodthreadtimeout-method有thread和signal两种。在Linux和macOS上signal方式更可靠因为它可以在任意阻塞点中断但在某些线程库中thread更安全。Windows上建议用thread因为信号处理的支持有限。要注意超时时间和fixture作用域的关系如果你设置了session级fixture超时只计算测试函数的执行时间不影响fixture的耗时。pytest-rerunfailures则用来处理网络抖动、外部服务偶发故障导致的用例失败。用法pytest --reruns 3 --reruns-delay 2它会自动重试失败的用例最多3次每次间隔2秒。这个插件适合集成测试但不建议在单元测试里滥用因为它会掩盖真正的非确定性bug。更好的做法是先在业务代码里排查偶发问题把重试当作最后一道保险。6.3 在CI流水线中运行pytestCI里跑pytest就两个核心诉求快速反馈和可读报告。通常一条命令搞定python -m pytest tests/ -q --junitxmlreport.xmljunitxml是JUnit格式的XML报告Jenkins、GitLab CI、GitHub Actions都能直接展示。在GitHub Actions里可以这样简化配置- name: Run tests run: | python -m pip install -r requirements-dev.txt python -m pytest tests/ -q --junitxmlreport.xml - name: Upload test report if: always() uses: actions/upload-artifactv4 with: name: pytest-report path: report.xmlif: always()很关键因为测试失败的时候CI默认会停止后面的步骤不加上它你的报告就传不上去了。覆盖率报告也可以一并上传这样每一次提交都能看到覆盖率的趋势。对于大型项目还可以用pytest-xdist并行加速通过-n auto自动利用机器所有CPU核心不过要留意测试代码是否存在共享文件或数据库状态并行环境会放大这些问题。7. 常见问题与排查技巧实录7.1 fixture不可达和scope冲突新手经常遇到fixture not found错误主要原因有两个fixture定义在conftest.py之外的位置或者fixture定义在与测试文件平级的目录但在兄弟目录里。pytest查找fixture的顺序是当前测试模块、当前目录的conftest.py、逐级向上到根目录。如果把fixture放在某一个子包的conftest.py里它就只对该子包下的测试可见。scope冲突则是另一个高频问题。比如你定义了一个session作用域的参数却在一个function作用域的fixture里引用了它导致测试函数期望的是独立实例结果拿到的是同一个对象。解决方法尽量让fixture的作用域小于等于它依赖的fixture作用域。如果确实需要session级的对象但每个测试都要重置状态可以在session级fixture里提供一个“重置”方法让测试在调用时显式处理。7.2 参数化id可读性参数化多了以后测试报告里会出现test_login[env0-token0]这种让人摸不着头脑的id。定位失败用例时你不得不再看参数表去对应是哪组数据。解决方式是自定义展示名称pytest.mark.parametrize( api_client, [ pytest.param({base_url: https://staging.example.com}, idstaging), pytest.param({base_url: https://prod.example.com}, idprod), ], indirectTrue, )这样报告里就能看到test_login[staging]、test_login[prod]。如果使用pytest_generate_tests动态生成参数也可以在metafunc.parametrize里传ids参数运行时根据参数值构造可读名称。保持测试报告可读是项目迭代到中期之后不得不重视的事。7.3 测试隔离与全局状态污染测试用例之间最怕共享可变状态。一个典型的坑是某个fixture返回一个全局配置字典测试A修改了字典里的某个字段测试B再使用同一个fixture时看到的配置已经是改过的。即使fixture设为function作用域如果它引用的是模块级单例对象问题依然存在。我踩过的坑是写了一个load_configfixture内部使用了lru_cache缓存第一次调用后就把配置缓存住了后续所有测试都拿到同一份配置。测试A为了模拟线上环境改动了配置结果直接污染了其他测试。排查了很久才找到原因——缓存生效了fixture本身没有问题但缓存的对象被共享了。解决方法是修改fixture让它每次返回一份深拷贝或者在测试中只改动局部数据不影响全局缓存对象。如果项目里已经有一个单例模块被多个测试引用一个快速有效的隔离手段是在autousefixture里每次测试前记录并恢复所有相关模块级状态pytest.fixture(autouseTrue) def _restore_global_state(): original_state deepcopy(module_state.__dict__) yield module_state.__dict__.clear() module_state.__dict__.update(original_state)这种方案能兜底但它会掩盖设计问题长期来看还是应该把可变单例对象改成依赖注入。我自己在实际操作中最深的体会是测试框架再强大也替代不了对被测代码可测试性的思考。好的组件边界、清晰的依赖方向、尽量少的隐式全局状态才是让pytest高级功能真正发挥价值的前提。如果哪天你发现某个测试怎么都没法隔离不妨回头看看生产代码是不是耦合得太紧。这比在测试里不断堆补丁重要得多。
pytest高级用法详解：fixture、mock、参数化与异步测试实战
聊到Python测试框架pytest几乎是绕不开的那个名字。很多项目从unittest迁移到pytest之后最直观的感受就是代码量下降了测试的可读性和效率明显提升。但大多数团队只用了它基础的assert和fixture功能真正让它拉开差距的高级用法——比如动态参数化、猴子补丁、异步测试、插件协同——反而用得很少。这篇博文我想从自己实际项目的经验出发把pytest里那些“高级但日常用得上”的测试技术拆开讲透包括fixture的作用域设计、mock外部依赖、异步事件循环的处理、覆盖率与CI集成以及我在真实工程里踩过的坑。无论你是刚开始写测试还是已经写了几年这些内容应该都能让你对pytest有一个更系统的理解。1. 为什么是pytest从unittest到pytest的工程化演进1.1 断言风格与failure输出的差异先从一个最容易被忽略的差异说起断言。Python原生的assert在unittest里基本是“能用但不友好”一个断言失败只告诉你AssertionError具体两个值差在哪、哪些部分不匹配要自己加msg或者打印日志才能看出来。pytest重写了断言机制当你写assert user.name admin失败时它会自动展示左右两侧的实际值对于字典、列表这类复杂结构还会用diff的方式标出哪里不一致。这意味着测试代码可以回归到最朴素的写法不用刻意去记assertEqual、assertIn、assertRaises这么一套API。团队新人上手成本也低很多只要会写assert就能写pytest用例。我见过不少项目从unittest迁移过来单是把断言从self.assertEqual改成assert这一点就删掉了大量样板代码而测试意图反而更清晰了。1.2 fixture机制解决了什么问题fixture大概是pytest和unittest最大的分水岭。unittest里每个测试类靠setUp和tearDown准备和清理环境一旦用例之间的公共数据变多就得继承一个又一个BaseTestCase或者写一堆工具函数在类内部调用。pytest的fixture则是声明式的依赖注入测试函数声明需要什么参数pytest就去查找和创建对应的fixture。这种设计让“准备环境”和“测试逻辑”彻底解耦。比如你要测数据库操作可以定义一个db_sessionfixture负责建连和销毁测试函数只需要参数里写db_sessionpytest会自动传入。更关键的是fixture可以跨文件复用不需要继承任何基类。你的用例是函数、类、还是模块fixture都能覆盖粒度由你决定。这让测试代码变成了一组可以自由组合的积木而不是一棵强制继承的树。1.3 插件生态与conftest的作用pytest的定位从来不是一个孤立的框架而是一个插件平台。官方维护的插件加上社区贡献的插件几乎覆盖了测试周期的每个环节覆盖率有pytest-cov重试有pytest-rerunfailures超时控制有pytest-timeout异步支持有pytest-asyncio还有各种报告格式、mock集成、Django/Flask/SQLAlchemy的适配插件。插件的加载入口通常放在conftest.py这个文件是pytest的“局部配置中心”。它不需要被importpytest会自动发现它并且它的作用域只覆盖当前目录及子目录。你可以把fixture、钩子函数、命令行选项都定义在这里。合理拆分conftest.py能让你项目的测试基础设施变得非常干净根目录放全局的fixture每个模块目录放自己领域的fixture互不干扰。2. 高级fixture作用域、工厂模式和依赖注入2.1 fixture作用域与自动使用fixture的scope参数决定了它什么时候创建、什么时候销毁。默认是function也就是每个测试函数都重新执行一次可选值还有class、module、package和session。作用域越大重复执行的成本越低但也要承担状态泄漏的风险。举个例子一个建立数据库连接的操作如果设计成function作用域几百条用例就会建立几百次连接慢到让人怀疑人生。把它改成session作用域整个测试进程只用一次性能提升非常明显。但你要想清楚这个连接是否允许被多个测试用例共享以及是否需要在每个用例之间重置状态。我自己的经验是无状态或者只读的依赖用session或module有状态且用例会修改状态的依赖老老实实用function。autouse参数的意思是“自动使用”不需要测试函数主动声明参数。比如你希望每个用例执行前都清空某个临时目录就可以定义一个autouseTrue的fixture。但autouse一定要慎用尤其在外部依赖上因为它在测试文件里是隐形的别人看用例时很难发现这个副作用存在。2.2 通过yield实现setup/teardownfixture里在yield之前的代码相当于setupyield之后的代码相当于teardown。这个语法比unittest的setUp/tearDown更贴合实际场景因为一个fixture可以同时负责准备和清理而且清理阶段即使测试抛异常也会执行。一个典型的场景是文件系统临时目录import pytest import tempfile import os pytest.fixture def tmp_project(): with tempfile.TemporaryDirectory() as td: os.makedirs(os.path.join(td, src)) yield td测试函数拿到的是tmp_project路径测试结束之后不管断言是否失败TemporaryDirectory都会自动清理掉。这种“上下文管理器风格”的fixture特别适合托管资源数据库连接、文件句柄、网络监听端口、浏览器实例都可以在yield前后做准备和回收。另外要留意的坑是如果yield之前就抛异常了那么yield后面的清理代码不会执行而pytest会标记这个fixture为error。所以如果setup阶段本身就可能失败你需要在fixture内部用try/finally来兜底确保部分创建的资源也能被释放。2.3 工厂模式与request参数有时候一个fixture不能只返回一个固定对象它需要根据测试用例的不同输入创建不同的数据。比如你要测试创建用户的接口不同用例需要不同角色的用户。这时可以把fixture设计成“工厂”fixture本身返回一个函数测试用例调用这个函数并传入参数。pytest.fixture def make_user(db_session): counter 0 def _make_user(usernameNone, roleviewer): nonlocal counter counter 1 username username or fuser_{counter} user User(usernameusername, rolerole) db_session.add(user) db_session.commit() return user return _make_user然后测试里这样用def test_admin_can_delete(make_user): admin make_user(roleadmin) # ...需要说明的是工厂里面捕获了一个counter变量每次调用生成唯一用户名。这种闭包设计在简单的fixture 参数不能满足时非常实用。配合request参数你还可以在工厂内部拿到当前测试节点的信息比如request.node.name用来生成与用例名相关的测试数据。2.4 动态参数化fixture普通参数化是把参数列表写在pytest.mark.parametrize上但如果参数依赖fixture的返回值或者参数集合需要根据某个文件、数据库动态生成就要靠pytest_generate_tests钩子或request.getfixturevalue了。我常用的一种模式是“fixture间接参数化”pytest.fixture def api_client(request): env request.param return APIClient(base_urlenv[base_url], tokenenv[token]) pytest.mark.parametrize( api_client, [ {base_url: https://staging.example.com, token: staging-token}, {base_url: https://prod.example.com, token: prod-token}, ], indirectTrue, ) def test_login(api_client): resp api_client.post(/login, json{username: admin}) assert resp.status_code 200indirectTrue告诉pytest参数名对应的不是普通参数而是一个fixturepytest会把参数值作为request.param传给fixture。这样你就可以针对不同环境、不同配置重复执行同一组用例而测试函数本身完全不需要改。这是数据驱动测试里强烈推荐的手法。3. 参数化与自定义标记数据驱动测试的正确姿势3.1 parametrize参数组合pytest.mark.parametrize是pytest最常用的数据驱动工具。它可以同时组合多个参数名也可以多次使用装饰器形成笛卡尔积。举一个实际例子测试一个字符串转换函数你需要覆盖正常输入、空字符串、特殊字符、Unicode字符等。import pytest def parse_csv_line(line): return [x.strip() for x in line.split(,)] pytest.mark.parametrize( raw,expected, [ (a,b,c, [a, b, c]), (a, b, c, [a, b, c]), (, []), (你,好, [你, 好]), (a,,c, [a, , c]), ], ) def test_parse_csv_line(raw, expected): assert parse_csv_line(raw) expected这里有个细节如果其中某个参数在运行时依赖另一个fixture可以只对某几个参数做parametrize另外的参数由fixture注入。pytest会自动把参数化生成的用例id组合成可读的测试节点名称比如test_parse_csv_line[raw0-expected1]。如果你希望id更直观可以用ids参数指定每个参数组合的显示名这对测试报告尤其友好。3.2 自定义mark与条件跳过pytest允许你通过pytest.mark.xxx给用例打标签然后在运行的时候选择或排除这些标签。最常见的做法是区分冒烟测试、接口测试、慢测试pytest.mark.smoke def test_health_check(): ... pytest.mark.slow def test_heavy_calculation(): ...在pytest.ini里注册标记可以避免pytest的警告[pytest] markers smoke: 冒烟测试用例 slow: 运行时间较长的用例 integration: 依赖外部服务的集成测试运行的时候pytest -m smoke and not slow就可以只跑冒烟但排除慢用例。另一个实用场景是条件跳过有些用例只在特定Python版本或特定依赖安装时才有效pytest.mark.skipif正好派上用场。比如pytest.mark.skipif(sys.platform win32, reason该功能仅在Linux下验证) def test_linux_only_feature(): ...要是跳过的原因是在运行时才能确定比如某个外部服务没起来可以在测试里用pytest.skip()主动跳过这样不会把环境缺失误判为测试失败CI上也不会产生红色告警。3.3 pytest_generate_tests钩子内置的parametrize覆盖不了所有场景尤其当你希望参数化信息来自fixture或者外部配置时。这时可以在conftest.py里实现pytest_generate_tests钩子。def pytest_generate_tests(metafunc): if db_url in metafunc.fixturenames: db_urls load_available_database_urls() metafunc.parametrize(db_url, db_urls, indirectTrue)这段代码的意思是如果一个测试函数或fixture需要db_url这个参数pytest就会调用钩子从你的配置源里动态读取数据库列表并生成多个测试实例。相比在测试用例上硬编码参数这种方式让参数来源与测试代码彻底分离新增一个数据库环境不需要改用例代码只需要改配置源。不过钩子函数要小心设计因为它会影响所有测试。最好用fixturenames判断条件避免误伤无关用例。4. 用mock和猴子补丁隔离外部依赖4.1 monkeypatch fixturepytest内置的monkeypatchfixture是轻量级测试替身的首选。它能把某个对象、环境变量、系统路径临时替换掉测试结束后自动还原。它的使用方式非常简单def test_get_user_with_default_role(monkeypatch): def fake_load_config(): return {default_role: editor} monkeypatch.setattr(config.load_config, fake_load_config) assert get_user().role editormonkeypatch.setattr支持字符串形式的点路径也支持直接传对象。我推荐优先用字符串路径因为这样替换的是模块里的引用而不是对象本身的属性更不容易误伤同一对象的其他依赖。对于环境变量的修改用monkeypatch.setenv(DB_HOST, localhost)测试结束后环境变量也能恢复。注意monkeypatch只在当前测试函数生命周期内有效所以非常适合用来覆盖临时行为。它的替代方案是unittest.mock.patch两者并不是完全等价。monkeypatch更简洁也更贴合pytest的风格unittest.mock提供了更丰富的mock对象如assert_called_once_with适合需要断言调用参数和次数的场景。4.2 unittest.mock在pytest中的结合虽然pytest原生支持monkeypatch但当你需要模拟一个复杂的第三方类并验证它的调用顺序时unittest.mock.Mock更顺手。典型场景是测试发送邮件、上传文件、调用支付网关等外部操作。from unittest.mock import Mock, patch def test_send_notification(): with patch(app.services.send_email) as mock_send: mock_send.return_value {status: sent} result notify_user(userexample.com) assert result[status] sent mock_send.assert_called_once_with( touserexample.com, templatewelcome, )在pytest里推荐用monkeypatch来安装Mock对象避免使用with patch出现缩进嵌套def test_send_notification(monkeypatch): mock_send Mock(return_value{status: sent}) monkeypatch.setattr(app.services.send_email, mock_send) result notify_user(userexample.com) mock_send.assert_called_once_with(touserexample.com, templatewelcome)这样测试函数保持扁平结构读起来更清晰。Mock对象还能设置side_effect来模拟异常mock_send.side_effect TimeoutError(smtp timeout)这在测试失败路径时特别有用你可以验证代码是否正确捕获了外部异常并做了降级处理。4.3 模拟外部API的实战案例假设你的服务里有一段代码启动时会向外部接口请求一个Token然后拿着Token下载报表。这个流程在单元测试里肯定不能真连外网所以需要把两层都mock掉。def fetch_report(api_client, report_id): token api_client.get_token() headers {Authorization: fBearer {token}} return api_client.download(f/reports/{report_id}, headersheaders)测试写法def test_fetch_report(monkeypatch): class FakeClient: def __init__(self): self.calls [] def get_token(self): self.calls.append(get_token) return fake-token def download(self, path, headers): self.calls.append((download, path, headers)) return breport-content fake_client FakeClient() result fetch_report(fake_client, rpt_001) assert result breport-content assert fake_client.calls[0] get_token assert fake_client.calls[1][0] download这里没有使用任何Mock库而是直接写了一个有状态的手写替身。对于简单场景手写替身反而比Mock更直观因为调用链一目了然。如果外部依赖接口很复杂再考虑用专门的库如responses或pytest-mock。pytest-mock是一个常用插件它把unittest.mock包装成了mockerfixture用起来更简洁def test_fetch_report_with_mocker(mocker): mocker.patch.object(APIClient, get_token, return_valuefake-token) mocker.patch.object(APIClient, download, return_valuebreport-content) result fetch_report(APIClient(), rpt_001) assert result breport-contentpytest-mock在测试结束后会自动清理mock不需要手动stopall也是我目前在项目里优先采用的方案。5. 异步测试与pytest-asyncio5.1 环境准备与事件循环作用域现在越来越多的代码是async/await写成的pytest默认的事件循环并不支持直接运行异步测试函数。pytest-asyncio插件补上了这个缺口。安装之后你需要给异步测试函数加上标记import pytest pytest.mark.asyncio async def test_async_operation(): result await some_async_function() assert result ok如果不加markpytest会把它当作普通函数执行然后报“coroutine was never awaited”的警告。另一个关键点是事件循环的作用域。pytest-asyncio默认使用function作用域也就是说每个异步测试函数都会创建一个新的事件循环。这个设计有助于隔离但如果你有很多异步fixture频繁创建事件循环会有额外开销。你可以在配置里改成session作用域让所有异步测试共享一个事件循环[pytest] asyncio_mode auto asyncio_default_fixture_loop_scope sessionasyncio_mode auto这个选项很值得推荐它让pytest自动识别async def测试函数并运行不需要手动加pytest.mark.asyncio。不过对于团队协作我建议显式声明因为隐性行为在排查问题时容易让人困惑。5.2 异步fixture与async测试函数异步fixture的写法和普通fixture差不多只是需要把fixture定义成async def并且用yield来做teardownimport pytest pytest.fixture async def async_client(): client await create_http_client() yield client await client.close()注意异步fixture不需要加pytest.mark.asynciopytest-asyncio会自动处理。但如果asyncio_mode strict默认模式测试函数必须显式带markfixture则不受此限制。如果混用同步fixture和异步fixturepytest决定依赖顺序时会根据是否有I/O等待来调度你尽量不要在同步fixture里去调用异步函数否则会卡在事件循环上。实在需要的话可以用asyncio.run()包一层但那样会新建一个独立事件循环要谨慎处理循环之间的资源传递。6. 插件与集成覆盖率、超时、重试和CI6.1 pytest-cov与覆盖率阈值写测试不是为了追求100%覆盖率但没有覆盖率数字团队很容易“自我感动”。pytest-cov可以帮你统计行覆盖率、分支覆盖率并输出到控制台或生成XML/HTML报告。通常配合pytest.ini里的addopts使用[pytest] addopts --covmy_package --cov-reporthtml --cov-reportterm-missing --cov-fail-under80--covmy_package指定统计哪个包--cov-reportterm-missing会在终端列出没有覆盖到的行号--cov-fail-under80表示如果覆盖率低于80%pytest会返回非零退出码CI会失败。这个阈值需要根据项目实际调整太高的阈值会逼着团队写一堆没有测试价值的异常分支太低又起不到保护作用。我的习惯是先让覆盖率工具跑起来看趋势再逐步提高阈值。6.2 pytest-timeout与pytest-rerunfailures超时控制在集成测试里几乎是必需品。pytest-timeout可以给每个测试设置超时时间超时后强制中断避免某个用例挂起导致整个测试套件卡住。pytest --timeout60 --timeout-methodthreadtimeout-method有thread和signal两种。在Linux和macOS上signal方式更可靠因为它可以在任意阻塞点中断但在某些线程库中thread更安全。Windows上建议用thread因为信号处理的支持有限。要注意超时时间和fixture作用域的关系如果你设置了session级fixture超时只计算测试函数的执行时间不影响fixture的耗时。pytest-rerunfailures则用来处理网络抖动、外部服务偶发故障导致的用例失败。用法pytest --reruns 3 --reruns-delay 2它会自动重试失败的用例最多3次每次间隔2秒。这个插件适合集成测试但不建议在单元测试里滥用因为它会掩盖真正的非确定性bug。更好的做法是先在业务代码里排查偶发问题把重试当作最后一道保险。6.3 在CI流水线中运行pytestCI里跑pytest就两个核心诉求快速反馈和可读报告。通常一条命令搞定python -m pytest tests/ -q --junitxmlreport.xmljunitxml是JUnit格式的XML报告Jenkins、GitLab CI、GitHub Actions都能直接展示。在GitHub Actions里可以这样简化配置- name: Run tests run: | python -m pip install -r requirements-dev.txt python -m pytest tests/ -q --junitxmlreport.xml - name: Upload test report if: always() uses: actions/upload-artifactv4 with: name: pytest-report path: report.xmlif: always()很关键因为测试失败的时候CI默认会停止后面的步骤不加上它你的报告就传不上去了。覆盖率报告也可以一并上传这样每一次提交都能看到覆盖率的趋势。对于大型项目还可以用pytest-xdist并行加速通过-n auto自动利用机器所有CPU核心不过要留意测试代码是否存在共享文件或数据库状态并行环境会放大这些问题。7. 常见问题与排查技巧实录7.1 fixture不可达和scope冲突新手经常遇到fixture not found错误主要原因有两个fixture定义在conftest.py之外的位置或者fixture定义在与测试文件平级的目录但在兄弟目录里。pytest查找fixture的顺序是当前测试模块、当前目录的conftest.py、逐级向上到根目录。如果把fixture放在某一个子包的conftest.py里它就只对该子包下的测试可见。scope冲突则是另一个高频问题。比如你定义了一个session作用域的参数却在一个function作用域的fixture里引用了它导致测试函数期望的是独立实例结果拿到的是同一个对象。解决方法尽量让fixture的作用域小于等于它依赖的fixture作用域。如果确实需要session级的对象但每个测试都要重置状态可以在session级fixture里提供一个“重置”方法让测试在调用时显式处理。7.2 参数化id可读性参数化多了以后测试报告里会出现test_login[env0-token0]这种让人摸不着头脑的id。定位失败用例时你不得不再看参数表去对应是哪组数据。解决方式是自定义展示名称pytest.mark.parametrize( api_client, [ pytest.param({base_url: https://staging.example.com}, idstaging), pytest.param({base_url: https://prod.example.com}, idprod), ], indirectTrue, )这样报告里就能看到test_login[staging]、test_login[prod]。如果使用pytest_generate_tests动态生成参数也可以在metafunc.parametrize里传ids参数运行时根据参数值构造可读名称。保持测试报告可读是项目迭代到中期之后不得不重视的事。7.3 测试隔离与全局状态污染测试用例之间最怕共享可变状态。一个典型的坑是某个fixture返回一个全局配置字典测试A修改了字典里的某个字段测试B再使用同一个fixture时看到的配置已经是改过的。即使fixture设为function作用域如果它引用的是模块级单例对象问题依然存在。我踩过的坑是写了一个load_configfixture内部使用了lru_cache缓存第一次调用后就把配置缓存住了后续所有测试都拿到同一份配置。测试A为了模拟线上环境改动了配置结果直接污染了其他测试。排查了很久才找到原因——缓存生效了fixture本身没有问题但缓存的对象被共享了。解决方法是修改fixture让它每次返回一份深拷贝或者在测试中只改动局部数据不影响全局缓存对象。如果项目里已经有一个单例模块被多个测试引用一个快速有效的隔离手段是在autousefixture里每次测试前记录并恢复所有相关模块级状态pytest.fixture(autouseTrue) def _restore_global_state(): original_state deepcopy(module_state.__dict__) yield module_state.__dict__.clear() module_state.__dict__.update(original_state)这种方案能兜底但它会掩盖设计问题长期来看还是应该把可变单例对象改成依赖注入。我自己在实际操作中最深的体会是测试框架再强大也替代不了对被测代码可测试性的思考。好的组件边界、清晰的依赖方向、尽量少的隐式全局状态才是让pytest高级功能真正发挥价值的前提。如果哪天你发现某个测试怎么都没法隔离不妨回头看看生产代码是不是耦合得太紧。这比在测试里不断堆补丁重要得多。