“测试代码”到底算不算“正经代码”我在不同团队里见到过两种极端一种人觉得写测试就是浪费时间跑通业务就行另一种人把测试当成产品一样精心维护。接触Pytest之后我越来越倾向于后者。如果你还在用print()加“手动点一点”的方式验证代码或者已经用unittest写到怀疑人生那么这篇关于Pytest框架入门的文章就是写给你看的。Pytest不只是一个测试框架它把断言、固件fixture、参数化、插件体系整合成一套非常顺手的工具链让我在写单元测试和自动化测试时从“完成任务”变成了“享受过程”。1. 为什么是Pytest从一个让人头疼的测试场景说起1.1 其实我们一开始只是想省点事先讲个我实际遇到的场景。早先维护一个订单处理模块里面有个计算折扣的函数逻辑不算复杂根据会员等级、订单金额、是否节假日算出最终折扣。当时验证方式很原始写一段临时脚本改几个参数跑一下用print看结果对不对。一次改完优惠规则漏测了“节假日叠加会员折扣”这个分支线上出了故障。复盘的时候大家一致认为是“测试不充分”。但深入想问题不在“没有测试”而在“测试方式不可持续”。手工验证的问题很明显没有记录、不可重复、覆盖面靠感觉。你今天验证了这三种情况明天改完代码可能只验证了一种。等函数越来越多、模块之间开始互相调用这种验证方式迟早会失控。这时候需要的是能够自动化运行的、可回归的测试用例。一开始团队里有人提议用unittestPython标准库自带的测试框架功能其实都够。但写起来总觉得有点啰嗦要继承TestCase类断言要用一堆assertEqual、assertTrue之类的方法setUp和tearDown写起来也不够直观。更关键的是用例多了以后运行反馈不够友好失败信息要靠自己猜。后来我试着把一个小项目改用Pytest第一次跑完就被它的输出惊艳到了——哪个文件哪一行什么断言失败期望值和实际值直接列在眼前修改测试代码的欲望一下子就上来了。1.2 常见测试框架之间的取舍很多人入门测试框架时会在unittest、nose、pytest之间纠结。我个人的看法是如果从零开始一个新项目直接选Pytest几乎不需要犹豫。unittest的优势是“零依赖”Python自带的任何环境都能跑。它的劣势也在这里设计偏重写测试像在写模板代码而且它的断言体系是方法调用形式失败信息全靠msg参数去补写起来很累。nose曾经是对unittest的补充但项目维护状态不佳新代码不建议选它。Pytest则走了另一条路——用原生assert断言用普通函数写用例用fixture管理前置和清理逻辑配合插件机制几乎要什么有什么。从维护成本看Pytest的另一个明显优势是“约定优于配置”。你不需要记住复杂的类继承关系测试文件、测试函数、测试类只要按命名规则创建它就能自动收集。团队协作时新人上手成本极低。我见过一个刚转测试开发的同事花了半小时看了一遍官方入门文档第二天就能独立给新模块写测试了。1.3 Pytest凭什么能被称作“更优雅”“优雅”这个词听起来虚但落到具体使用上其实很实在。我理解Pytest的优雅体现在三个层面。第一断言的自然性。写测试时用Python原生的assert语句失败时Pytest会自动重写断言表达式告诉你left right这个比较里左右两边到底是什么值。不用像unittest那样记一堆assertAlmostEqual、assertDictEqual的方法名。第二fixture的参数化注入。测试函数需要什么前置条件、什么数据直接在参数里声明Pytest按依赖关系去构造。这让测试代码非常干净前置条件和测试逻辑彻底分离。第三插件生态。覆盖率、HTML报告、并行执行、Mock、数据库测试基本上你能想到的测试需求都有人写好了插件等着你。2. 快速上手Pytest环境准备与第一个用例2.1 安装Pytest与项目环境在动手之前先准备好环境。Pytest本身是Python库用pip安装即可。我建议在任何项目里都先用虚拟环境隔离依赖避免全局环境被搞乱。python -m venv .venv source .venv/bin/activate # Windows下是 .venv\Scripts\activate pip install pytest装完可以用下面命令确认版本pytest --version我见过有人在没激活虚拟环境的情况下直接pip install pytest结果装到了系统Python里后面项目里的依赖版本冲突排查了半天。虚拟环境的习惯一开始就要养成。如果你想在IDE里调试测试比如PyCharm或者VS Code都需要把默认测试运行器改成Pytest。以VS Code为例需要安装Python扩展然后在设置里搜索“python testing”把测试框架选为pytest之后编辑器会自动发现测试用例并且提供单用例运行的入口。这个配置很值得做因为日常开发中“只跑一个用例”的需求是高频操作命令行虽然有表达式选择但IDE里点一下的效率更高。2.2 写出第一个测试用例Pytest最简单的用例就是一个普通函数函数内部用assert做断言。比如被测模块calculator.py里有个加法函数def add(a, b): return a b对应的测试文件test_calculator.pyfrom calculator import add def test_add(): assert add(2, 3) 5 def test_add_negative(): assert add(-1, 1) 0这里没有任何类、没有继承、没有setUp几个函数就组成了可用用例。运行方式pytest或者指定文件pytest test_calculator.py运行结果会以绿色和红色区分通过/失败失败时还会显示具体的断言对比。我第一次看到失败输出时有点意外它直接告诉我assert 2 2 5失败了左边等于4右边等于5一眼就能定位问题。2.3 测试发现与收集规则Pytest能自动找到测试用例靠的是约定好的命名规则。具体来说测试文件命名为test_*.py或者*_test.py。测试函数命名为test_*。测试类命名为Test*并且类里的方法命名为test_*。这些规则组合起来Pytest会在你指定的目录里递归扫描把符合条件的用例全部收集起来。这里有个细节测试类名用Test开头但类里不要写__init__方法否则会影响用例收集。测试类主要还是为了组织同一类功能的用例如果你习惯纯函数式的写法也完全没问题。当初我从unittest迁移时遇到一个坑测试类直接从unittest.TestCase继承类名也是TestFooPytest确实能收集但如果类里既有unittest风格的断言又有普通assert输出信息的可读性就会打折扣。建议既然选了Pytest就用Pytest的方式写不要混搭。2.4 从命令行到配置文件用例少的时候命令行参数就够了但工程复杂之后需要把重复参数沉淀到配置文件里。Pytest支持pytest.ini、pyproject.toml、conftest.py等多种配置方式我习惯用pytest.ini最直观。[pytest] testpaths tests addopts -v -s python_files test_*.py python_functions test_*testpaths指定扫描目录addopts是每次运行都默认追加的选项-v是详细输出-s是显示print内容。这里有个取舍默认我建议不要加-s因为测试输出应该是干净的用print调试是临时的行为。但团队内部如果大家习惯保留日志也可以加看你们自己的约定。3. 核心功能拆解断言、fixture、参数化与标记3.1 断言库让失败信息直接告诉你“哪里错了”Pytest对assert的增强是它最吸引人的特性之一。普通Python的assert失败时只会抛出AssertionError不会告诉你变量的实际值。Pytest则不同它会分析断言语句的上下文重新执行并提取中间值。举个例子def test_discount(): assert calculate_discount(100, vip) 85如果实际算出的是80失败信息会显示E assert 80 85 E where 80 calculate_discount(100, vip)这种信息在你写复杂业务断言时价值巨大。你不用再回去加print逐行排查失败信息本身就在帮你定位。对于字典、列表、集合这类容器Pytest的断言增强同样友好。比如两个字典比对失败它会用逐行-和标出两边差异。我建议写测试时放弃unittest风格的assertEqual全部改用原生assert。一开始可能会觉得少了一些专用的“几乎相等”“包含子串”之类的方法但Pytest通过数学运算符重写同样支持浮点近似比较比如assert abs(0.1 0.2 - 0.3) 1e-6有些场景确实需要额外辅助比如检查异常用pytest.raisesimport pytest def test_divide_by_zero(): with pytest.raises(ZeroDivisionError): x 1 / 0with pytest.raises(...)不仅能验证是否抛异常还能捕获异常对象继续断言消息内容def test_invalid_input_message(): with pytest.raises(ValueError) as exc_info: validate_age(-1) assert age must be positive in str(exc_info.value)3.2 fixture把前置条件从测试函数里拆出来fixture是Pytest区别于其他框架最标志性的设计。所谓fixture就是“测试前准备、测试后清理”的完整逻辑单元。它可以是构造数据、连接数据库、创建临时文件也可以只是返回一个配置值。先看一个最基础的fixture用法import pytest pytest.fixture def user_data(): return {name: Alice, level: vip} def test_user_has_default_credit(user_data): assert user_data[level] viptest_user_has_default_credit的参数列表里声明了user_dataPytest发现参数名和fixture函数名一致就会自动调用user_data函数并把返回值传给测试函数。这种“按需注入”的方式比setUp里面去self.xxx赋值要直观得多。但fixture的价值远不止返回数据。它真正的威力来自两部分作用域和依赖。fixture可以指定scope控制它的生命周期。默认是“函数级”也就是每个用例都重新执行一遍。可选值有scope参数生命周期适用场景function每个测试函数执行一次默认常规数据准备隔离性好class每个测试类执行一次类内用例共享较重的资源module每个模块执行一次模块级共享比如读取配置文件session整个测试会话执行一次全局共享的数据库连接、浏览器实例比如连接数据库是重量级操作如果每个用例都重新连接测试耗时成倍增加。可以这样设计import pytest pytest.fixture(scopesession) def db_connection(): conn create_connection(dsnsqlite:///:memory:) yield conn conn.close()这里yield之前是“准备阶段”yield之后是“清理阶段”。当所有测试结束时conn.close()会被执行。这种写法比传统tearDown干净很多因为清理逻辑和资源定义是绑定在一起的。fixture还可以直接依赖另一个fixture实现层级化的准备逻辑。比如pytest.fixture def user(db_connection): return create_user(db_connection) def test_user_profile(user): assert user.profile is not None这样写的好处是每个测试函数只需要声明它真正需要的依赖Pytest会自动构建依赖树。3.3 fixture的作用域与自动使用fixture有一个容易被忽视的“自动使用”模式。通过autouseTrue可以让fixture在不被参数声明的情况下自动在指定作用域内生效。通常在两类场景下有用一类是“每个用例都需要执行的全局清理”比如清理临时目录另一类是“对测试环境做基础准备”比如设置环境变量。pytest.fixture(autouseTrue) def clean_temp_dir(): ensure_empty_dir(/tmp/test_runtime) yield cleanup(/tmp/test_runtime)我个人的经验是autouse要慎用。因为它的执行是隐式的新人阅读测试代码时不容易发现“为什么这里多了一步清理”。如果确实要用最好在fixture命名上写清楚意图比如上面就叫clean_temp_dir一目了然。一旦autouse的fixture数量超过两三个建议review一下是否真的每个用例都需要。3.4 参数化一份用例跑多组数据测试里最常做的事就是“同样的逻辑多组输入”。以前用循环写用例断言失败时很难分清是哪一组数据出了问题。Pytest的parametrize装饰器就是为解决这个痛点设计的。import pytest pytest.mark.parametrize( price, discount_rate, expected, [ (100, 0.8, 80), (200, 0.5, 100), (300, 1.0, 300), ], ) def test_apply_discount(price, discount_rate, expected): assert apply_discount(price, discount_rate) expected运行时Pytest会展开成三条用例每条用例的ID会带上参数值比如test_apply_discount[100-0.8-80]。哪一组数据失败一眼就能在报告里看出来。参数化还可以叠加多个装饰器实现多维度组合。比如同时测不同会员等级和商品类别的折扣组合pytest.mark.parametrize(level, [normal, vip, svip]) pytest.mark.parametrize(category, [book, digital, food]) def test_category_and_level_discount(level, category): result calculate_discount(level, category) assert result 0这里会生成3乘3共9条用例。参数化还有一个进阶用法是给参数指定ID让输出更好读pytest.mark.parametrize( case, [ pytest.param({price: 100, expected: 80}, idvip-100), pytest.param({price: 200, expected: 150}, idsvip-200), ], ) def test_case(case): ...等到用例数量大了你会发现好用的ID简直救命的特别是结合后面的“选择用例执行”功能。3.5 marker跳过、预期失败与自定义标记实际测试过程中有些用例在特定条件下不该跑比如需要外部服务、依赖特定操作系统、或者已知BUG但还没修复。处理这些情况Pytest用marker机制。跳过用例分无条件跳和条件跳pytest.mark.skip(reason支付网关暂未接入) def test_payment(): ... pytest.mark.skipif(sys.platform win32, reason该特性仅支持Linux) def test_unix_only_feature(): ...预期失败的用例指的是“我知道它会挂但先标记出来不要算作回归失败”。这对遗留系统迁移非常有用pytest.mark.xfail(reason待重构的旧算法) def test_legacy_algorithm(): assert legacy_calculate(100) 999还有个用法是自定义marker打标签比如标记哪些用例属于“冒烟测试”pytest.mark.smoke def test_login(): ...然后在运行的时候指定只跑冒烟pytest -m smoke不过自定义marker需要先注册否则Pytest会给出警告。在pytest.ini里加markers smoke: 冒烟测试用例 slow: 耗时较长的用例这里有个真实踩坑经验一开始没有注册slow这个marker虽然测试能跑但警告信息一直在刷屏。后来把marker统一注册到配置文件输出干净了同事跑测试时也不会质疑“是不是代码报错”。4. 插件生态与工程化覆盖率、报告与并行执行4.1 pytest-cov让覆盖率不再是黑板报覆盖率是衡量测试完整度的一个指标但不能作为唯一标准。不过它确实是发现“测试盲区”的有效工具。Pytest生态里最常用的覆盖率插件是pytest-cov。安装pip install pytest-cov运行pytest --covcalculator --cov-reportterm-missing--covcalculator指定统计哪个模块--cov-reportterm-missing会在控制台输出每个模块的覆盖率以及哪些行没有覆盖到。先解释一下覆盖率的常见口径行覆盖line coverage、分支覆盖branch coverage。行覆盖指的是代码中被执行到的行数占总行数的比例简单易懂但可能存在“每行都过了但某个分支没走到”的情况。分支覆盖更进一步统计if/else各个分支是否都被执行过。我建议至少在核心业务模块开启分支统计pytest --covcalculator --cov-branch --cov-reportterm-missing覆盖率数值不用一味追求100%。在真实的项目里我见过覆盖率85%但核心逻辑被测得很透的也见过覆盖率97%但全是“为了覆盖而覆盖”的脆弱用例。覆盖率工具是用来辅助找盲区的不是用来KPI的。把覆盖率门槛设到CI里也很简单pytest --covcalculator --cov-fail-under80如果低于80%命令会返回非零状态码CI就会失败。这个阈值建议按团队实际情况调整不要一开始定太高否则大家会用各种取巧的方式刷数据。4.2 pytest-html与allure报告也能拿得出手命令行输出的测试结果适合开发自测。但如果要给团队、给项目管理者看需要更正式的报告。两个常用方案是pytest-html和Allure。pytest-html使用最简单pip install pytest-html pytest --htmlreport.html它会生成一个独立的HTML文件包含用例列表、耗时、通过/失败状态、失败时的报错堆栈。还可以在运行后把报告嵌入到CI产物里方便追溯。如果需求更重比如需要按功能模块聚合、查看历史趋势、自动截屏附到报告里那么选Allure。Allure需要两部分一是allure-pytest插件负责在运行时收集结果二是allure命令行工具负责把结果渲染成报告网页。pip install allure-pytest pytest --alluredirallure-results allure serve allure-resultsallure serve会启动一个本地服务并在浏览器打开可视化报告。这套方案在接口测试和UI自动化项目里尤其常见。我的建议是小团队或单个模块用pytest-html就够了Allure的部署成本略高等测试用例规模到几百条以上再上也不迟。4.3 pytest-xdist多进程并行测试测试用例多到一定规模跑一次要十分钟以上并行执行就变得很有吸引力。pytest-xdist是Pytest的分布式执行插件。安装pip install pytest-xdist使用pytest -n auto-n auto会自动根据CPU核数决定并行进程数。也可以指定进程数比如-n 4。并行测试最大的坑是“用例之间的数据隔离”。比如多个用例同时往同一个文件写数据、同时使用同一个测试数据库就会出现莫名其妙的失败。所以用pytest-xdist之前先检查项目里有没有共享的可变资源。共享资源要么想办法做到并发安全要么在fixture里做好隔离。我遇到过一个项目单进程跑没问题一到-n auto就随机失败最后定位到是多个测试进程共用了临时文件名改成按进程ID区分之后一切正常。另一个小技巧是pytest-xdist和--durations配合使用可以很方便找出拖慢整个测试套件的“慢用例”pytest -n auto --durations5输出会列出最耗时的5条用例。优化测试速度前先看清瓶颈在哪。4.4 conftest.py全局可复用fixture的集中营conftest.py是Pytest里一个比较特殊的文件。它不需要被导入Pytest会自动发现它并把它定义的fixture和钩子提供给当前目录及其子目录下的所有测试。合理的做法是把公共fixture放在根目录或某个作用域的conftest.py里比如统一的数据库连接fixture、登录token fixture、临时目录清理fixture。我见过一个常见错误把所有的fixture都塞进根目录的一个conftest.py导致每个测试模块都隐式依赖了一堆根本用不到的资源测试启动时间被拉长。fixture也应该按目录、按功能模块分层放置与测试代码的组织结构保持一致。conftest.py还有一个用途是提供“命令行自定义选项”。通过钩子函数添加参数再在fixture中读取就能让测试运行时动态切换环境比如后端地址def pytest_addoption(parser): parser.addoption(--api-base, actionstore, defaulthttp://localhost:8080) pytest.fixture def api_base(request): return request.config.getoption(--api-base)5. 实操全记录一个订单服务测试的完整改造5.1 背景一段“靠print调试”的历史代码为了把前面这些功能串起来我模拟一次完整的改造过程。假设有一个订单模块order_service.py提供了三个函数create_order、apply_discount、query_order_status。历史代码本身逻辑不多但没有任何自动化测试开发时全靠print和手动调用。原代码大概是这样的# order_service.py import time def create_order(user_id, items): if not items: raise ValueError(items should not be empty) order { order_id: ORD str(int(time.time())), user_id: user_id, items: items, status: CREATED, } return order def apply_discount(order, discount_rate): if not 0 discount_rate 1: raise ValueError(discount_rate must be in (0, 1]) total sum(item[price] for item in order[items]) order[discount_total] total * discount_rate return order def query_order_status(order_id, order_map): order order_map.get(order_id) if not order: raise KeyError(order not found) return order[status]这段代码的问题不在逻辑而在“没法证明它对”。折扣边界条件、空订单列表、查不存在的订单这些分支全靠肉眼确认。5.2 第一轮先写出最基本的用例第一轮改造先覆盖常规路径和主要异常。测试文件放在tests/test_order_service.pyimport pytest from order_service import create_order, apply_discount, query_order_status def test_create_order_normal(): order create_order(U001, [{name: book, price: 100}]) assert order[user_id] U001 assert order[status] CREATED assert order[order_id].startswith(ORD) def test_create_order_empty_items(): with pytest.raises(ValueError): create_order(U001, []) def test_apply_discount_normal(): order create_order(U001, [{name: book, price: 100}]) apply_discount(order, 0.8) assert order[discount_total] 80.0 def test_apply_discount_invalid_rate(): order create_order(U001, [{name: book, price: 100}]) with pytest.raises(ValueError): apply_discount(order, 1.5) def test_query_order_status_not_found(): with pytest.raises(KeyError): query_order_status(NO_ORD, {})这个版本已经能跑但存在两个让我不满意的地方create_order的调用在每个用例里重复出现而且order_id依赖时间戳不好断言具体值。于是进入第二轮。5.3 第二轮引入fixture与参数化用fixture统一管理订单创建的前置数据pytest.fixture def sample_order(): return create_order(U001, [{name: book, price: 100}, {name: pen, price: 20}]) def test_apply_discount_normal(sample_order): apply_discount(sample_order, 0.8) assert sample_order[discount_total] 96.0用参数化覆盖折扣率的多种取值pytest.mark.parametrize( rate, expected, [ (1.0, 120.0), (0.5, 60.0), (0.8, 96.0), ], ) def test_apply_discount_multiple_rates(sample_order, rate, expected): apply_discount(sample_order, rate) assert sample_order[discount_total] expected这里顺带发现一个设计问题apply_discount修改的是order原对象多个用例如果共享同一个fixture实例会出现“数据污染”。虽然当前fixture是function级别每个用例拿到的都是新对象但如果改成module级别就会踩坑。我最后给它加了只读约束在测试里先复制对象再断言避免后续用例被前面的修改影响。5.4 第三轮接口级联与mock如果被测模块里依赖外部HTTP接口测试就不能真的发起网络请求。Pytest生态通常用pytest-mock插件来模拟外部依赖。pip install pytest-mockpytest-mock给测试函数注入一个mocker对象用法和unittest.mock基本一致但更贴合Pytest风格def test_order_payment_calls_api(mocker, sample_order): mock_api mocker.patch(order_service.payment_api.call) mock_api.return_value {success: True} result pay_for_order(sample_order) assert result[success] is True mock_api.assert_called_once()要注意mocker.patch的路径是“字符串”它patch的是目标模块里引用外部模块的那个名字而不是外部模块本身。这里有个经典误区如果order_service.py里写的是from payment_sdk import call_payment那么patch路径应该是order_service.call_payment而不是payment_sdk.call_payment。写错路径真实调用就会在测试里跑出去轻则测试变慢重则产生外部副作用。mock带来的一个重要问题是“安全错觉”。mock越多测试对真实代码的保障就越弱。我的原则是能不用mock就不用mock必须用时把mock范围控制在“外部边界”比如第三方SDK、网络请求、时间函数。尽量不要mock自己项目内部的业务函数否则测试很容易变成“自己验证自己”。5.5 最终结果与覆盖率改造完成之后整个测试文件有20多个用例覆盖了正常路径、异常路径、边界值、外部依赖。运行一次pytest tests/test_order_service.py -v --covorder_service --cov-branch --cov-reportterm-missing输出里会显示order_service模块的行覆盖率和分支覆盖率假设最终达到92%。对于这个模块来说剩下的8%多是一些异常兜底逻辑评估后暂时没有专门覆盖的必要。这个改造过程给我的体会是测试不是一次写完就结束的它和被测代码一起演化。fixture的抽取、参数化的整理、mock边界的划定每一步都需要根据代码变化做调整。写测试和写业务代码一样需要持续重构。6. 常见问题与排查技巧实录6.1 用例收集不到症状是运行pytest显示“no tests ran”。先按顺序排查这几个地方测试文件名是否以test_开头或_test结尾。测试函数名是否以test_开头。测试文件是否在testpaths指定目录内。pytest.ini里有没有写错python_files配置。有个容易忽略的场景是在类里定义了test_方法但类名不是Test开头或者类里有__init__方法导致Pytest无法实例化。遇到这类问题先用pytest --collect-only命令看看Pytest到底收集了什么。这个命令会列出所有被识别到的用例排查效率很高。6.2 fixture作用域混乱、数据污染运行测试时单独跑某一个用例通过全部跑起来就随机失败优先怀疑是fixture共享了可变数据。举个例子fixture返回了一个字典某个用例往字典里加了键后续用例拿到的就是被污染的数据。解决思路有两个一是让fixture返回不可变对象比如MappingProxyType或者每次返回新副本二是明确每个用例需要的数据是独立的用function级fixture而不是session级。session级fixture适合真正重量级的资源比如数据库连接、Redis连接不适合存业务数据。排查数据污染时我常用一个笨但有效的方法在fixture的yield前后打日志观察用例调用顺序和数据内容。pytest -s会把print输出打出来配合用例名称基本能定位是哪一个用例修改了共享数据。6.3 断言语义与断言失败信息如果测试的断言信息不够直观先确认用的是原生assert还是unittest的assertEqual。Pytest只对原生assert做表达式重写unittest风格的断言方法仍然可用但输出信息没那么友好。另一个常见问题是浮点比较。直接assert 0.1 0.2 0.3永远失败因为浮点有精度问题。Pytest确实没有默认提供“约等于”断言处理方案是手动控制误差范围或者借助pytest.approxfrom pytest import approx assert 0.1 0.2 approx(0.3)approx会按默认相对误差和绝对误差来判断很适合计算类模块。6.4 乱码、中文路径、环境变量问题Windows环境或中文路径下偶尔会遇到控制台输出乱码。多数情况下设置好Python编码即可比如在pytest.ini里加[testenv] setenv PYTHONIOENCODINGutf-8如果测试代码本身包含中文注释在文件头部没有声明编码的老版本环境下容易报SyntaxError。现代Python 3默认UTF-8一般不用管。但pytest读取某个文件时如果遇到编码问题可以显式指定运行时的编码环境变量PYTHONUTF81 pytest6.5 从unittest迁移的坑老项目用unittest写的用例迁移到Pytest并不需要全部推翻。Pytest能直接运行unittest.TestCase子类。但有几个细节要注意setUp和tearDown在Pytest里依然会执行这是兼容性的保障。但如果新旧风格的fixture混用执行顺序可能和你预期的不一致。建议迁移时保持“一个测试模块只使用一种风格”。另一个坑是unittest里的断言方法如果暴露在测试函数中被调用Pytest的assert重写不会生效失败信息可读性依然差。迁移策略我建议分两步走第一步把unittest用例跑起来第二步逐步把断言改成原生assert。6.6 常见问题速查表问题现象可能原因解决方式no tests ran文件或函数命名不符合规则检查命名使用pytest --collect-only用例随机失败fixture共享可变数据改用function级fixture或返回副本断言失败信息太简略使用了unittest风格断言改成原生assertmock没有生效patch路径错误patch“使用方”的导入位置运行超慢有sleep或真实网络请求用mock代替外部调用检查fixture作用域报告中文乱码环境编码问题设置PYTHONIOENCODINGutf-8多进程随机失败共享临时文件或数据库按进程隔离资源写在最后一点个人经验Pytest学起来不难但用好它需要持续打磨。我见过太多项目只是用它跑一个简单的assertfixture和参数化完全没用上测试代码最后变成了业务代码的“低价值复读机”。真正让Pytest发挥价值的地方其实是它引导你思考“测试应该怎么组织”fixture让前置条件可复用参数化让输入输出可追踪marker让测试环境可控插件让测试结果可展示。这些设计理念往小说是工具用法往大说是一种测试工程的思维方式。如果你正在为现有测试代码的混乱而头疼或者准备给新模块建立第一道自动化防线Pytest是一个非常值得投入的选择。用它写一阵子测试再回头看那些全靠“print 手动点”的日子你会明白什么叫“更优雅”。
