1. 项目概述为什么我们需要深入掌握pytest如果你写过Python测试或者哪怕只是听说过自动化测试pytest这个名字大概率已经在你耳边出现过无数次了。它早已不是那个“比unittest更好用的测试框架”那么简单了。今天我想从一个干了多年自动化测试的老兵视角跟你聊聊pytest。我们不是要泛泛而谈它的优点而是要深入到它的骨髓里看看在真实的项目实战中我们到底该怎么用它才能让它真正成为我们手中的利器而不是一个仅仅停留在“会用”层面的工具。pytest的核心魅力在于它的“约定大于配置”和强大的可扩展性。这意味着你不需要写一堆样板代码来声明一个测试类只要函数名以test_开头它就能被自动发现并执行。这极大地降低了入门门槛。但真正让pytest在复杂项目中大放异彩的是它背后那套精密的“用例管理”机制、丰富到令人惊叹的“插件”生态以及灵活且强大的“断言”系统。这三个方面恰恰是决定一个测试框架能否支撑起企业级自动化测试体系的关键。很多人会用pytest test_file.py但面对成百上千个测试用例如何高效组织、如何定制化执行、如何生成漂亮的报告、如何让断言信息更清晰时就有点抓瞎了。这篇文章我们就来彻底解决这些问题。2. 核心思路构建可维护、可扩展的测试架构在开始敲代码之前我们必须先想清楚测试代码的架构。好的架构能让后续的维护成本降低90%。基于pytest我推荐的核心思路是“分层管理 插件驱动 断言清晰”。分层管理指的是将测试数据、测试逻辑、测试用例和测试环境清晰地分离开。你不能把所有东西都堆在一个test_xxx.py文件里。想象一下当业务逻辑变更你需要修改上百个测试文件里的同一个测试数据时那将是灾难。因此我们需要利用pytest的conftest.py、fixture以及目录结构来构建层次。插件驱动意味着不要重复造轮子。pytest社区有海量的插件来解决各种通用问题比如生成HTML报告、控制用例执行顺序、做分布式测试、与CI/CD工具集成等。我们的目标是学会挑选和运用这些插件让它们为我们服务把精力集中在业务测试逻辑本身。断言清晰是测试可读性和可维护性的生命线。一个失败的测试如果只告诉你AssertionError那你得花半天时间去代码里找到底哪里不对。pytest的断言重写机制能自动为你展示断言两边的值但这还不够。我们需要更结构化的断言方式来清晰地表达我们的预期。接下来我们就从这三个支柱出发深入每一个细节。2.1 用例管理的艺术从目录结构到Fixture设计用例管理是基石。一个混乱的测试目录会让所有后续工作举步维艰。2.1.1 科学的目录结构我推荐的项目结构通常长这样project_root/ ├── src/ # 你的源代码 ├── tests/ # 所有测试代码 │ ├── unit/ # 单元测试 │ │ ├── __init__.py │ │ ├── conftest.py # 单元测试专用的fixture │ │ ├── test_models.py │ │ └── test_utils.py │ ├── integration/ # 集成测试 │ │ ├── __init__.py │ │ ├── conftest.py │ │ └── test_api_integration.py │ ├── functional/ # 功能/端到端测试 │ │ ├── __init__.py │ │ ├── conftest.py │ │ └── test_user_flow.py │ ├── data/ # 测试数据JSON, YAML, CSV等 │ │ ├── users.json │ │ └── products.yaml │ ├── fixtures/ # 跨模块使用的复杂fixture定义可选 │ │ └── database.py │ └── conftest.py # 项目根级别的conftest定义全局fixture ├── pytest.ini # pytest配置文件 ├── requirements-test.txt # 测试依赖 └── ...为什么这么设计按测试类型分层单元、集成、功能测试的关注点和执行环境不同。分开管理便于单独运行如pytest tests/unit和配置不同的fixture。独立的conftest.pyconftest.py的作用域是它所在的目录及其子目录。这意味着你可以在tests/下定义全局fixture如日志初始化在tests/functional/下定义只用于功能测试的fixture如浏览器驱动。这实现了fixture的精准作用域控制避免了命名冲突和不必要的初始化开销。集中管理测试数据将数据文件放在tests/data/下通过编写辅助函数来读取使得数据与代码分离。当测试数据需要更新时你只需要修改数据文件而不是去每个测试用例里找。2.1.2 Fixture测试的“脚手架”与依赖注入Fixture是pytest的灵魂它用于准备测试环境、提供测试数据、清理资源。理解Fixture的生命周期和作用域是关键。生命周期和作用域作用域function默认每个测试函数运行一次、class、module、package、session。合理选择作用域能大幅提升测试速度。例如数据库连接通常用session作用域这样所有测试只建立一次连接。自动使用使用pytest.fixture(autouseTrue)可以让fixture自动应用于其作用域内的每一个测试无需在测试函数中声明。常用于全局设置如日志配置、临时目录创建。一个实战中的复杂Fixture示例 假设我们需要一个带缓存的数据库客户端并且每个测试模块需要独立的测试数据库。# tests/conftest.py import pytest import tempfile import os from your_app.database import DatabaseClient pytest.fixture(scopesession) def database_config(): 会话级别的配置所有测试共享。 # 可以从环境变量或配置文件读取 return { host: os.getenv(TEST_DB_HOST, localhost), port: 5432, user: test_user, } pytest.fixture(scopemodule) def test_database_name(database_config): 为每个测试模块生成一个唯一的数据库名。 # 使用模块名和随机后缀确保隔离 import uuid module_name __import__(__main__).__file__.split(/)[-1].replace(.py, ) return ftest_{module_name}_{uuid.uuid4().hex[:8]} pytest.fixture(scopemodule) def database_client(database_config, test_database_name): 模块级别的数据库客户端fixture。 1. 创建临时数据库 2. 建立连接 3. 运行迁移脚本如alembic 4. 在测试结束后销毁数据库 client DatabaseClient(**database_config) # 创建测试库 client.execute(fCREATE DATABASE {test_database_name};) # 切换到测试库并运行迁移 client.switch_database(test_database_name) run_migrations(client) yield client # 这是测试真正使用的对象 # 测试后的清理工作 client.close() # 切换回主连接以删除测试库 admin_client DatabaseClient(**database_config) admin_client.execute(fDROP DATABASE IF EXISTS {test_database_name};) admin_client.close() pytest.fixture def db_session(database_client): 函数级别的会话fixture用于单个测试。 每个测试在一个独立的事务中运行测试后自动回滚保证测试间隔离。 session database_client.create_session() transaction session.begin() yield session transaction.rollback() session.close()在测试中使用# tests/unit/test_user_model.py def test_create_user(db_session): # 自动注入db_session fixture from your_app.models import User user User(nameAlice, emailaliceexample.com) db_session.add(user) db_session.commit() fetched_user db_session.query(User).filter_by(emailaliceexample.com).first() assert fetched_user is not None assert fetched_user.name Alice # 由于事务回滚这个用户数据不会污染其他测试注意yield是fixture定义中的分水岭。yield之前的代码是“设置”阶段yield之后的代码是“清理”阶段。即使测试失败清理代码也会执行这保证了资源的正确释放对于数据库连接、文件句柄、网络端口等资源至关重要。2.1.3 参数化测试用一份代码覆盖多种场景pytest.mark.parametrize是避免编写重复测试代码的神器。它允许你为同一个测试函数提供多组输入参数和期望输出。基础用法import pytest pytest.mark.parametrize(input_str, expected, [ (35, 8), (2*4, 8), (6/2, 3.0), ]) def test_eval(input_str, expected): assert eval(input_str) expected高级技巧参数化组合与ID自定义当你有多个相互独立的参数需要组合测试时可以使用多个parametrize装饰器pytest会生成笛卡尔积。import pytest pytest.mark.parametrize(x, [0, 1, 2]) pytest.mark.parametrize(y, [10, 20]) def test_combination(x, y): # 这个测试会运行 3 * 2 6 次 assert (x y) 10 # 为每一组参数设置一个易读的ID在测试报告里更清晰 pytest.mark.parametrize( user_role, has_access, [ pytest.param(admin, True, idadmin_has_access), pytest.param(editor, True, ideditor_has_access), pytest.param(viewer, False, idviewer_no_access), pytest.param(guest, False, idguest_no_access), ], ) def test_access_control(user_role, has_access): result check_permission(user_role) assert result has_access从文件读取参数化数据 对于大量测试数据写在代码里不现实。我们可以从外部文件读取。# tests/data/login_cases.yaml - username: valid_user password: correct_pwd expected: login_success - username: valid_user password: wrong_pwd expected: invalid_password - username: unknown_user password: any_pwd expected: user_not_found # tests/test_login.py import pytest import yaml import os def load_login_cases(): data_file os.path.join(os.path.dirname(__file__), data, login_cases.yaml) with open(data_file, r) as f: cases yaml.safe_load(f) return cases pytest.mark.parametrize(case, load_login_cases()) def test_login_scenarios(case): # case 是一个字典包含了username, password, expected result login(case[username], case[password]) assert result.status case[expected]2.2 插件生态武装你的测试工作流pytest本身是一个内核精巧的框架它的强大能力通过插件体系无限扩展。下面介绍几个在实战中几乎必用的插件。2.2.1 pytest-html生成专业测试报告测试报告是向团队展示测试结果、追溯问题的重要产出。pytest-html插件可以生成美观的HTML报告。安装与基本使用pip install pytest-html pytest --htmlreport.html --self-contained-html--self-contained-html参数会将CSS样式内联到HTML中生成单个文件方便传递。定制化报告 你可以在conftest.py中钩住pytest的钩子函数向报告中添加额外信息比如环境变量、测试描述、自定义摘要。# conftest.py def pytest_configure(config): 在测试运行前调用用于添加全局信息。 config._metadata { 项目名称: 我的API测试项目, 测试环境: Staging, Python版本: 3.9, } def pytest_html_results_summary(prefix, summary, postfix): 修改HTML报告的摘要部分。 prefix.extend([fpstrong自定义信息/strong 本次测试重点关注登录模块。/p]) pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): 在每个测试项运行后调用可以获取测试结果并添加额外信息到报告。 outcome yield report outcome.get_result() if report.when call: # 只关注测试调用阶段忽略setup/teardown # 添加一个额外的链接或文本到报告 report.extra [] # 确保extra属性存在 if report.failed: # 例如失败时截图假设在UI测试中 # screenshot_path take_screenshot() # html fdivimg src{screenshot_path} alt失败截图 stylewidth:600px;/div # report.extra.append(pytest_html.extras.html(html)) pass2.2.2 pytest-xdist实现测试并行化当测试套件成百上千时串行执行会非常耗时。pytest-xdist插件可以让测试并行运行充分利用多核CPU。安装与运行pip install pytest-xdist pytest -n auto # 自动检测CPU核心数并启动对应数量的worker进程 pytest -n 4 # 指定启动4个worker进程并行化的注意事项测试隔离并行测试的核心要求是测试之间不能有状态依赖。你的测试必须是独立的。这意味着要避免使用共享的全局变量、共享的数据库记录除非有很好的隔离机制如我们之前用fixture为每个模块创建独立数据库。function和class作用域的fixture在默认的dist模式下是每个worker独立一份的但session作用域的fixture可能会被多个worker共享需要特别小心。资源竞争如果测试涉及文件写入、端口绑定等需要确保资源路径或端口号是动态的、唯一的避免worker间冲突。可以使用tempfile模块或pytest的tmp_pathfixture。调试困难输出信息会交错在一起。建议在并行运行时使用-q安静模式或--tbshort来简化输出并将详细日志重定向到每个worker独立的文件。不是万能药对于I/O密集型如大量数据库查询、网络请求的测试并行化效果显著。对于纯CPU密集型的测试也要考虑Python的GIL限制。2.2.3 pytest-cov集成代码覆盖率测试写了但到底覆盖了多少代码pytest-cov插件可以无缝集成coverage.py在运行测试的同时收集覆盖率数据。安装与基本使用pip install pytest-cov pytest --covsrc # 计算src目录下的代码覆盖率 pytest --covsrc --cov-reporthtml # 生成HTML格式的覆盖率报告便于在浏览器中查看 pytest --covsrc --cov-reportterm-missing # 在终端输出报告并显示未覆盖的行配置.coveragerc文件 在项目根目录创建.coveragerc文件可以精细控制覆盖率分析。[run] source src # 指定要分析覆盖率的源代码目录 omit # 忽略某些文件 src/legacy/* */test_*.py */__pycache__/* [report] # 设置覆盖率通过的最低门槛 fail_under 80 # 忽略某些行如只有pass的语句 exclude_lines pragma: no cover def __repr__ raise AssertionError raise NotImplementedError if __name__ .__main__.:在CI中集成你可以在CI流水线中运行pytest --covsrc --cov-fail-under80如果覆盖率低于80%则使构建失败从而保证代码质量门槛。2.2.4 其他实用插件速览pytest-ordering: 控制测试用例的执行顺序谨慎使用测试应尽量独立。pytest-rerunfailures: 对失败的测试用例进行重试对付那些偶尔因网络抖动等原因失败的“脆皮”测试特别有用。pytest-timeout: 为测试用例设置超时时间防止某些测试卡死。pytest-mock: 集成了unittest.mock提供更便捷的mock和patch功能是单元测试的利器。pytest-asyncio: 用于测试异步asyncio代码。pytest-django / pytest-flask: 针对Django或Flask框架的专用插件提供了大量针对性的fixture和工具。2.3 断言详解从基础到高级技巧断言是测试的灵魂它定义了“什么是对的”。pytest对Python原生的assert语句进行了魔改使其在失败时能提供极其丰富的上下文信息。2.3.1 原生assert的魔力直接使用assertpytest会在断言失败时自动为你计算表达式的值并展示出来。def test_compare(): expected {name: Alice, age: 30, city: New York} actual {name: Alice, age: 31, city: Boston} assert actual expected运行失败时你会看到类似这样的输出E AssertionError: assert {name: Al...oston} {name: Al...ork} E Omitting 1 identical items, use -v to show E Differing items: E {age: 31} ! {age: 30} E {city: Boston} ! {city: New York} E Full diff: E - {age: 30, city: New York, name: Alice} E {age: 31, city: Boston, name: Alice}这比单纯的AssertionError有用太多了它直接告诉你字典中哪些键值对不一致。2.3.2 使用pytest-assume进行“软断言”默认情况下一个断言失败整个测试函数就停止了。但有时我们希望收集所有失败的断言最后再统一报告这在检查一个对象的多个属性时非常有用。这就需要pytest-assume插件。安装与使用pip install pytest-assumeimport pytest def test_multiple_checks(): result some_complex_operation() # 即使第一个断言失败后面的也会继续执行 pytest.assume(result.status_code 200) pytest.assume(error not in result.json()) pytest.assume(len(result.json()[data]) 0) # 所有断言执行完后如果有失败的会统一报告运行后你会看到所有失败的断言都被列了出来而不是在第一个失败点就停止。2.3.3 自定义断言信息当默认的断言信息不够清晰时你可以为assert语句添加自定义的错误信息。def test_custom_message(): user get_user(123) assert user.is_active, f用户 {user.id} ({user.name}) 应该处于活跃状态但当前状态是 {user.status}失败时你的自定义消息会显示出来这对于在复杂上下文中定位问题非常有帮助。2.3.4 针对异常和警告的断言测试不仅关心正常路径也要关心异常情况。pytest提供了简洁的上下文管理器来断言异常。import pytest def test_division_by_zero(): with pytest.raises(ZeroDivisionError) as exc_info: value 1 / 0 # 你还可以进一步检查异常的具体信息 assert exc_info.type is ZeroDivisionError # 检查异常信息字符串 assert division by zero in str(exc_info.value) # 断言会触发特定警告 import warnings def test_deprecation_warning(): with pytest.warns(DeprecationWarning, match.*old_function.*is deprecated.*): call_old_function()2.3.5 使用assertpy进行更优雅的断言第三方库虽然pytest的原生断言很强但有时我们想要更流畅、更面向对象的断言语法。assertpy库是一个很好的选择。pip install assertpyfrom assertpy import assert_that def test_with_assertpy(): result some_function() assert_that(result).is_not_none() assert_that(result.status_code).is_equal_to(200) assert_that(result.json()).contains_key(data) assert_that(result.json()[data]).is_length(5) assert_that(result.elapsed_time).is_less_than(1.0) # 响应时间小于1秒 # 链式调用非常流畅 assert_that(hello world).starts_with(hello).ends_with(world).contains( )assertpy提供了大量现成的断言方法让测试代码读起来更像自然语言尤其在断言复杂数据结构时非常清晰。3. 实战配置与高级技巧掌握了核心概念后我们来看看如何通过配置和技巧让pytest更好地融入你的开发工作流。3.1 精细化配置pytest.ini与命令行参数pytest.ini是pytest的主配置文件放在项目根目录。它可以固化你的常用选项避免每次都在命令行输入一长串参数。一个功能丰富的pytest.ini示例[pytest] # 1. 自动发现测试的路径和文件名规则 testpaths tests unit_tests # 在这些目录下寻找测试 python_files test_*.py *_test.py # 匹配这些文件模式 python_classes Test* *Test # 匹配这些类名模式 python_functions test_* # 匹配这些函数名模式 # 2. 添加默认的命令行参数 addopts -v # 详细输出 --strict-markers # 严格检查marker未注册的marker会报错 --tbshort # 发生错误时使用简短的traceback格式 --coloryes # 输出带颜色 -q # 安静模式与-v相反根据喜好选择 --durations10 # 显示最慢的10个测试 # 3. 注册自定义的marker标记 # 用于分类测试如pytest.mark.slow, pytest.mark.integration markers slow: marks tests as slow (deselect with -m not slow) integration: marks tests as integration tests (require external services) smoke: subset of tests for quick verification serial: tests that cannot run in parallel (for use with xdist) # 4. 配置日志确保测试输出和日志不干扰 log_cli true log_cli_level INFO log_cli_format %(asctime)s [%(levelname)s] %(name)s: %(message)s log_cli_date_format %Y-%m-%d %H:%M:%S # 5. 配置覆盖率如果使用pytest-cov # 这里通常不直接配置而是在命令行或tox.ini中指定但也可以设置默认值 # cov_args --covsrc --cov-reportterm-missing # 6. 设置自定义的基准目录影响tmpdir等fixture # basetemp /tmp/pytest-of-username通过标记Markers筛选测试 在测试函数或类上使用pytest.mark.xxx进行标记然后可以在运行时选择性地执行。# test_suite.py import pytest import time pytest.mark.slow def test_complex_calculation(): time.sleep(5) assert 1 1 2 pytest.mark.smoke def test_login(): assert login(user, pass) pytest.mark.integration def test_api_call(): # 调用外部API pass运行命令pytest -m smoke # 只运行标记为smoke的测试 pytest -m not slow # 运行所有非slow的测试 pytest -m integration or smoke # 运行integration或smoke的测试3.2 临时目录与文件处理测试经常需要创建临时文件。pytest提供了内置的tmp_path和tmpdirfixture后者返回py.path.local对象前者返回标准库pathlib.Path对象推荐使用tmp_path。def test_create_file_in_tmp(tmp_path): # tmp_path是一个Path对象指向一个临时目录 d tmp_path / sub d.mkdir() p d / hello.txt p.write_text(Hello, pytest!) assert p.read_text() Hello, pytest! assert len(list(tmp_path.iterdir())) 1这个临时目录在测试结束后会自动清理完全无需担心垃圾文件残留。3.3 测试跳过与条件跳过有时某些测试不应该在特定条件下运行比如缺少某个依赖、只在特定操作系统上。pytest提供了装饰器来处理。import pytest import sys pytest.mark.skip(reason这个功能尚未实现) def test_unimplemented_feature(): assert False pytest.mark.skipif(sys.version_info (3, 8), reason需要Python 3.8或更高版本) def test_feature_requires_py38(): # 使用了Python 3.8才有的语法或特性 pass def test_platform_specific(): if not sys.platform.startswith(linux): pytest.skip(此测试仅适用于Linux系统) # Linux特定的测试代码4. 常见问题与排查技巧实录在实际使用中你肯定会遇到各种奇怪的问题。这里记录了一些我踩过的坑和解决方案。4.1 Fixture作用域与生命周期陷阱问题一个session作用域的fixture比如数据库连接池在测试并行运行pytest-xdist时被多个worker进程共享导致数据竞争或连接混乱。排查与解决现象测试时好时坏出现一些随机性的数据错误或连接超时。排查首先确认是否使用了pytest-xdist。然后检查出问题的fixture的作用域。session和package作用域的fixture在xdist的--distload模式下是共享的。解决方案最安全将共享资源的fixture作用域降级为function或class确保每个测试或测试类独占一份。但这可能增加初始化开销。使用进程隔离如果必须共享确保资源本身是线程/进程安全的例如使用连接池且连接池本身是安全的。或者使用xdist的--distno模式即串行运行这些特定的测试通过marker标记。为每个worker创建独立资源可以利用pytest-xdist提供的worker_idfixture来为每个worker创建独立的资源标识如数据库名、临时目录。# 示例为每个xdist worker创建独立的测试数据库 def get_worker_db_name(worker_id): return ftest_db_worker_{worker_id} pytest.fixture(scopesession) def database_name(worker_id): # worker_id在非并行运行时是master return get_worker_db_name(worker_id)4.2 测试依赖与执行顺序问题测试用例之间存在隐式依赖比如测试A创建了一个全局状态测试B依赖这个状态。当测试顺序改变时B就可能失败。排查与解决现象单独运行测试B能通过但运行整个测试套件时B失败。排查使用pytest -v查看测试执行顺序。检查失败的测试是否依赖于其他测试留下的数据或状态如全局变量、数据库中的特定记录、文件系统中的文件。解决方案黄金法则确保每个测试都是独立的、幂等的。测试应该能按任何顺序运行且多次运行结果相同。使用Fixture所有测试依赖的状态都应该通过fixture来提供并在测试结束后由fixture负责清理。绝对不要依赖测试执行顺序。彻底清理在session或module作用域的fixture的清理阶段yield之后确保将所有修改过的状态还原。对于数据库可以在每个测试函数中使用事务并回滚如之前的db_sessionfixture所示。如果无法避免依赖极少数情况如性能测试的预热使用pytest-ordering插件强制指定顺序并明确用文档说明原因。但这应被视为最后的手段。4.3 断言失败信息不清晰问题对于复杂的自定义对象assert actual expected失败时pytest只能输出对象的内存地址无法知道内部属性的差异。排查与解决现象断言失败信息是AssertionError: assert CustomObject at 0x... CustomObject at 0x...毫无帮助。解决方案实现__repr__方法在你的类中实现一个清晰的__repr__方法pytest在输出对象时会调用它。class User: def __init__(self, id, name): self.id id self.name name def __repr__(self): return fUser(id{self.id!r}, name{self.name!r}) def test_user(): u1 User(1, Alice) u2 User(1, Bob) # 名字不同 assert u1 u2失败输出会变成AssertionError: assert User(id1, nameAlice) User(id1, nameBob)一目了然。 2.使用pytest_assertrepr_compare钩子高级你可以自定义特定类型比较时的断言输出。这需要在conftest.py中实现。# conftest.py def pytest_assertrepr_compare(config, op, left, right): if isinstance(left, User) and isinstance(right, User) and op : return [ Comparing User instances:, f id: {left.id} ! {right.id}, f name: {left.name} ! {right.name}, ]使用第三方库如attrs或dataclasses库来装饰你的类它们会自动生成高质量的__repr__和__eq__方法。4.4 插件冲突或加载失败问题安装了多个插件后pytest行为异常或者某些插件功能不生效。排查与解决现象命令行参数不识别、fixture找不到、报告格式错乱等。排查运行pytest --version查看已安装的插件列表确认目标插件是否在其中。检查插件版本兼容性。有时新版本的pytest可能与旧版插件不兼容。查看pytest.ini或setup.cfg中是否有冲突的配置。解决方案升级/降级尝试将相关插件和pytest升级到最新稳定版或回退到已知兼容的版本组合。清理.pytest_cache删除项目目录下的.pytest_cache文件夹这是一个缓存目录有时会导致奇怪的问题。最小化复现创建一个新的虚拟环境只安装pytest和出问题的插件看问题是否依然存在。这可以排除其他插件的干扰。查看插件文档许多插件有特定的加载顺序要求或配置方式。4.5 性能优化让测试跑得更快当测试套件庞大时速度就是生命。使用作用域更大的Fixture将耗时的初始化如启动Docker容器、建立数据库连接放到session或module作用域的fixture中而不是function。并行化使用pytest-xdist。这是提升I/O密集型测试速度最有效的方法。选择性运行pytest -k keyword只运行名称中包含keyword的测试。pytest --lf或pytest --last-failed只重新运行上一次失败的测试。pytest --ff或pytest --failed-first先运行上次失败的测试然后再运行其他的。Mock外部依赖对于单元测试使用unittest.mock或pytest-mock来模拟网络请求、数据库调用等慢速或不可靠的外部服务。这能极大提升测试速度和稳定性。禁用不必要的输出使用-q安静模式或--tbno不显示traceback来减少控制台输出这也能节省一点时间尤其是在CI环境中。5. 集成到CI/CD流水线自动化测试只有在CI/CD中自动运行才有价值。这里以GitHub Actions为例展示一个典型的配置。# .github/workflows/test.yml name: Python Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest strategy: matrix: python-version: [3.8, 3.9, 3.10, 3.11] # 多版本Python测试 steps: - uses: actions/checkoutv3 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-pythonv4 with: python-version: ${{ matrix.python-version }} - name: Install dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt pip install -r requirements-test.txt # 安装测试专用依赖pytest及插件 - name: Lint with flake8 run: | pip install flake8 flake8 src --count --max-complexity10 --statistics - name: Test with pytest run: | # 运行测试生成HTML和XML报告 pytest tests/ -v \ --covsrc \ --cov-reporthtml \ --cov-reportxml \ --junitxmljunit/test-results-${{ matrix.python-version }}.xml \ --htmlreport-${{ matrix.python-version }}.html \ --self-contained-html env: TEST_DB_HOST: localhost # 其他测试环境变量... - name: Upload pytest test results uses: actions/upload-artifactv3 if: always() # 即使测试失败也上传报告 with: name: test-results-py${{ matrix.python-version }} path: | report-*.html junit/ htmlcov/ - name: Upload coverage to Codecov uses: codecov/codecov-actionv3 with: file: ./coverage.xml flags: unittests name: codecov-umbrella这个工作流做了以下几件事在多个Python版本下运行测试。进行代码风格检查flake8。运行pytest并生成覆盖率报告HTML和XML、JUnit格式的测试结果许多CI系统能解析和HTML测试报告。将测试报告作为制品上传便于后续查看。将覆盖率数据上传到Codecov等服务。踩过无数坑之后我的体会是pytest的强大在于它的“约定”和“扩展”之间的完美平衡。新手可以快速上手而老手可以借助fixture、插件和钩子函数构建出极其复杂和强大的测试基础设施。最重要的不是记住所有参数和插件而是理解其设计哲学测试代码也是产品代码它同样需要良好的架构、清晰的表达和高效的执行。把每一次写测试都当成一次设计你会发现编写可维护的测试最终会反过来促使你写出更可测试、也就是更模块化、更清晰的业务代码。
