| 📦 工具名称 | 📅 首次发布 |
| 👤 作者Holger Krekel / pytest-dev团队 | ⭐ GitHub Stars |
🎯 解决了什么问题？
Python自带的unittest有三个让测试开发工程师抓狂的问题：
1. 太啰嗦 — 必须继承TestCase、必须以test_开头、断言要写self.assertXxx
2. 不好调试 — 失败信息不够清晰，不知道哪里出了问题
3. 扩展性差 — 加fixture、参数化、插件都要自己折腾
pytest的解法：让测试代码尽可能简洁，把复杂的事情交给框架。
⚡ 核心功能拆解
🔥 功能一：极简的测试写法
# unittest写法classTestCalculator(unittest.TestCase):deftest_add(self): result = add(1, 2) self.assertEqual(result, 3)# pytest写法deftest_add():assert add(1, 2) == 3 少了多少？少了继承、少了self、少了assertEqual。这就是pytest的核心哲学：能省就省。
🔧 测试开发视角：别小看这几行代码的简化。当你有500个测试用例的时候，pytest的简洁写法能帮你省下大量的维护时间。而且代码越少，出bug的概率越低。
🔧 功能二：fixture — 测试的"预制件"
fixture是pytest最强大的功能。你可以把数据库连接、测试数据、浏览器启动这些"准备工作"封装成fixture，测试用例直接拿来用：
@pytest.fixturedefdb_connection(): conn = create_connection()yield conn # 这里开始执行测试 conn.close() # 测试结束后自动清理deftest_query(db_connection): # 直接传参就能用 result = db_connection.execute("SELECT * FROM users")assert len(result) > 0 注意yield关键字：yield之前是setup，yield之后是teardown。比unittest的setUp/tearDown优雅太多了。
🔧 测试开发视角：fixture的scope参数（function/class/module/session）让你可以精确控制"这个准备工作跑一次还是每次测试都跑"。这在做API测试和数据库测试时特别有用——不用每次测试都重建数据库连接。
🎯 功能三：参数化 — 一组数据跑多个用例
@pytest.mark.parametrize("input, expected", [ (1, 2), (2, 4), (3, 6), (0, 0), (-1, -2), ])deftest_double(input, expected):assert double(input) == expected 5组数据自动生成5个测试用例，失败时清楚地告诉你哪组数据出了问题。
🔧 测试开发视角：参数化是测试开发的瑞士军刀。边界值测试、等价类划分、多语言测试……全都可以用参数化优雅地实现。比起复制粘贴5个几乎一样的测试函数，这种方式代码量减少了80%。
🔌 功能四：插件生态 — 1000+插件
pytest的插件生态是它最大的护城河：
🔧 测试开发视角：我做嵌入式测试的时候，用pytest-xdist把500个测试用例并行跑，时间从45分钟缩短到8分钟。插件生态就是pytest的"军火库"，你需要什么功能，基本都有现成的。
🔧 实战技巧：三个让你少踩坑的用法
📁 技巧一：conftest.py — 共享 fixture 的正确姿势
不用在每个测试文件里重复定义 fixture，放到 conftest.py 里，同目录及子目录的测试自动继承：
# tests/conftest.pyimport pytest@pytest.fixture(scope="session")defapi_client():"""整个测试会话只创建一次，所有测试共享""" client = APIClient(base_url="http://localhost:8000") client.login()yield client client.logout() 🔧 测试开发视角：conftest.py 可以嵌套，子目录的 conftest 会覆盖父目录的同名 fixture。建议按模块组织 conftest——tests/api/conftest.py 放 API 相关 fixture，tests/ui/conftest.py 放 UI 相关的。别把所有东西塞进一个 conftest，后期维护会疯。
🏷️ 技巧二：marker 标记 — 分类运行测试
不是所有测试每次都要跑。用自定义 marker 把测试分类，CI 只跑 smoke，全量留给夜间：
# 注册自定义标记（放到 pytest.ini 或 pyproject.toml）# [pytest]# markers =# smoke: 冒烟测试，快速验证核心功能# slow: 耗时测试@pytest.mark.smokedeftest_login():assert login("admin", "123456") == "success"@pytest.mark.slowdeftest_big_data_export(): result = export(10_000_000) # 一千万条数据assert result.status == "done"运行时用 -m 筛选：pytest -m smoke 只跑冒烟，pytest -m "not slow" 跳过耗时测试。
🔧 测试开发视角：我在项目里的实践是三级：smoke（5分钟内，每次push跑）、integration（30分钟，PR合并前跑）、e2e（2小时，凌晨定时跑）。用 marker + pytest-xdist 并行，smoke最快30秒跑完。
🪝 技巧三：hook 函数 — 你想在哪插入逻辑都行
pytest 提供了几十个 hook 点，让你在测试生命周期的任意阶段插入自定义逻辑。最常用的两个：
# conftest.pydefpytest_collection_modifyitems(config, items):"""收集完测试用例后：给所有用例自动打标记"""for item in items:if"api"in str(item.fspath): item.add_marker(pytest.mark.api)defpytest_runtest_makereport(item, call):"""每个测试执行后：失败时自动截图"""if call.when == "call"and call.excinfo is not None: driver.save_screenshot(f"failures/{item.name}.png") 🔧 测试开发视角：hook 是 pytest 的灵魂。上面这个截图 hook 在 UI 自动化里省了我无数时间——测试挂了，打开截图一看就知道页面卡在哪了。pytest_runtest_makereport 配合 call.when 还能区分是 setup 失败还是 teardown 失败。
👍 我觉得做得好的地方
| ✅ 优点• 上手极快，10分钟就能写出第一个测试• 断言失败信息非常清晰• fixture系统设计优雅• 插件生态无人能及• 与CI/CD工具链无缝集成• 社区活跃，文档完善 | ⚠️ 可以改进的地方• 学习曲线前期平缓，后期陡峭• 配置项多，新人容易迷茫• 并行执行时的测试隔离需要注意• 大型项目测试组织缺乏官方最佳实践 |
🤔 如果我是测试架构师，我会怎么做？
1. 建立pytest模板项目 — 新项目一键初始化，统一测试规范，不用每个项目重新配
2. 自定义pytest插件 — 把公司的测试工具链（日志收集、报告生成、环境管理）封装成内部插件
3. 搭建测试数据平台 — fixture从平台拉取测试数据，而不是硬编码在代码里
4. 测试用例分级 — 用pytest标记（mark）把用例分成P0/P1/P2，CI只跑P0，全量跑在夜间
🎯 适合谁用？
• 所有Python项目的测试（没有例外）
• 从unittest迁移过来的项目
• 需要搭建自动化测试框架的测试开发
• CI/CD流水线中的测试环节
• 不太适合：非Python项目（但有pytest的兄弟：Jest、Go test等）
📝 最后说两句
pytest成功的秘诀不是某个单一功能，而是它把"写测试"这件事的体验做到了极致。简洁的语法让你愿意写，强大的fixture让你能写好，丰富的插件让你什么都能测。
作为测试开发，pytest不是"要不要学"的问题，而是"你已经在用了吗"的问题。如果你还在用unittest，今天就切换过来。
下一篇预告
Playwright：微软出品的下一代浏览器自动化
