1. 项目概述为什么是pytest如果你写过Python代码尤其是写过一些稍微有点规模的脚本或者项目你大概率会和我一样经历过这样的场景改了一行代码然后心惊胆战地手动运行整个程序看看输出对不对或者打开浏览器点点点祈祷功能正常。这种“祈祷式开发”效率低不说关键是心里没底代码越写越不敢改。单元测试就是解决这个问题的“定心丸”。它让你能对代码的最小可测试单元通常是函数或方法进行独立验证确保每次修改都不会破坏原有逻辑。Python自带了unittest框架但说实话用起来有点繁琐。你需要写一个继承unittest.TestCase的类方法名要以test_开头用一堆self.assertEqual()这样的断言。代码结构显得冗长不够Pythonic。而pytest的出现几乎重塑了Python社区的测试习惯。它没有unittest那些条条框框你只需要写一个以test_开头的函数用普通的assert语句它就能自动发现并运行你的测试。这种极简的哲学加上异常强大的插件生态比如生成HTML报告、并行测试、数据库夹具等让pytest迅速成为Python单元测试的事实标准。简单来说pytest让写测试变成一件轻松、甚至有点愉悦的事情。它降低了测试的入门门槛却提供了专业级的强大功能。无论你是刚入门的新手还是维护大型项目的老鸟pytest都能显著提升你的代码质量和开发信心。接下来我们就从零开始手把手带你用pytest搭建一个完整的单元测试实战环境。2. 环境准备与项目结构规划工欲善其事必先利其器。在开始写测试之前我们先要把环境和项目结构搭好。一个好的结构能让测试代码和业务代码清晰分离便于管理和维护。2.1 创建虚拟环境与安装pytest首先为你的项目创建一个独立的虚拟环境。这是Python开发的最佳实践可以避免不同项目间的依赖冲突。# 在项目根目录下 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate激活虚拟环境后命令行提示符前通常会显示(venv)。接下来安装pytest。虽然只写单元测试的话pytest基础包就够了但我强烈建议一并安装pytest-cov它可以用来生成测试覆盖率报告让我们直观地看到哪些代码被测试覆盖了。pip install pytest pytest-cov安装完成后可以通过pytest --version来验证安装是否成功。2.2 规划一个清晰的项目目录结构一个混乱的目录结构是项目腐化的开始。对于包含测试的项目我推荐以下结构my_project/ ├── src/ # 存放项目源代码 │ └── my_package/ # 你的包 │ ├── __init__.py │ ├── calculator.py # 示例一个计算器模块 │ └── utils.py # 示例工具函数模块 ├── tests/ # 存放所有测试代码 │ ├── __init__.py # 让pytest将tests识别为一个包可选但有好处 │ ├── conftest.py # pytest的本地配置文件放夹具(fixture)等 │ ├── test_calculator.py # 针对calculator.py的测试 │ └── test_utils.py # 针对utils.py的测试 ├── .gitignore # Git忽略文件 ├── pyproject.toml # 现代Python项目配置文件依赖、工具配置 └── README.md为什么这样规划src布局将源代码放在src目录下是一种被称为“src-layout”的推荐做法。这能确保你在测试和开发时导入的是已安装的包而不是当前目录下的模块可以避免很多因导入路径引起的诡异问题。独立的tests目录将测试代码与业务代码物理分离结构清晰。pytest默认能智能地发现test_*.py或*_test.py文件。conftest.py文件这是pytest的“魔力”文件之一。你可以在这里定义被多个测试文件共享的fixture夹具后面会详细讲。pytest会自动发现它无需显式导入。pyproject.toml这是现在管理项目依赖和工具配置如pytest参数的首选文件比旧的setup.py和setup.cfg更现代统一。在pyproject.toml中我们可以配置pytest的默认选项例如[tool.pytest.ini_options] testpaths [tests] # 告诉pytest在哪个目录找测试 addopts -v --tbshort # 默认参数-v显示详细信息--tbshort简化错误回溯 pythonpath [src] # 将src目录加入Python路径方便导入这样每次运行pytest时就不用再敲一堆命令行参数了。实操心得项目初期就定好结构并坚持使用src-layout和独立的tests目录能为后续的代码维护、打包分发、以及CI/CD集成省去无数麻烦。很多团队在项目变大后重构目录结构那才是真正的痛苦。3. 编写你的第一个pytest测试理论说再多不如动手写一个。让我们先创建一个简单的业务模块然后为它写测试。3.1 创建被测试的业务代码在src/my_package/calculator.py中我们写一个简单的计算器类class Calculator: 一个简单的计算器类。 def add(self, a: float, b: float) - float: 返回两个数的和。 return a b def subtract(self, a: float, b: float) - float: 返回a减去b的结果。 return a - b def multiply(self, a: float, b: float) - float: 返回两个数的乘积。 return a * b def divide(self, a: float, b: float) - float: 返回a除以b的结果。 如果除数为0抛出ValueError。 if b 0: raise ValueError(除数不能为零) return a / b这个类很简单有四个基本运算方法。注意divide方法包含了一个边界情况除零的处理。3.2 编写对应的测试文件现在在tests/test_calculator.py中编写测试# 导入要测试的类。因为我们在pyproject.toml中配置了pythonpath包含src所以可以直接这样导入。 # 如果没有配置可能需要使用 from src.my_package.calculator import Calculator 或设置PYTHONPATH。 from my_package.calculator import Calculator # 测试类不是必须的pytest可以直接测试函数。但用类组织相关测试是常见做法。 class TestCalculator: 测试Calculator类。 # 每个测试方法都必须以 test_ 开头 def test_add(self): 测试加法功能。 calc Calculator() result calc.add(2, 3) # 使用简单的assert语句进行断言 assert result 5 def test_subtract(self): 测试减法功能。 calc Calculator() assert calc.subtract(5, 3) 2 assert calc.subtract(0, 5) -5 # 测试负数情况 def test_multiply(self): 测试乘法功能。 calc Calculator() assert calc.multiply(3, 4) 12 assert calc.multiply(0, 100) 0 # 零乘任何数为零 def test_divide_normal(self): 测试正常的除法功能。 calc Calculator() assert calc.divide(6, 3) 2 assert calc.divide(5, 2) 2.5 # 测试浮点数结果 def test_divide_by_zero(self): 测试除数为零时的异常抛出。 calc Calculator() # 使用pytest.raises上下文管理器来断言会抛出特定异常 import pytest with pytest.raises(ValueError) as exc_info: calc.divide(10, 0) # 还可以进一步检查异常信息是否匹配 assert str(exc_info.value) 除数不能为零3.3 运行测试并解读结果在项目根目录下打开终端确保虚拟环境已激活直接运行pytest你会看到类似这样的输出 test session starts platform darwin -- Python 3.9.0, pytest-7.0.0, pluggy-1.0.0 rootdir: /path/to/my_project, configfile: pyproject.toml plugins: cov-4.0.0 collected 5 items tests/test_calculator.py ..... [100%] 5 passed in 0.02s 太棒了5个测试全部通过用5个点.表示。pytest的输出非常清晰collected 5 itemspytest自动发现了5个以test_开头的测试函数。[100%]进度条显示所有测试已运行完毕。5 passed最终结果5个测试通过。现在我们故意在test_add中制造一个错误把断言改成assert result 6再运行pytest -v-v表示详细模式 test session starts ... collected 5 items tests/test_calculator.py::TestCalculator::test_add FAILED [ 20%] tests/test_calculator.py::TestCalculator::test_subtract PASSED [ 40%] ... FAILURES __________________________ TestCalculator.test_add ___________________________ self test_calculator.TestCalculator object at 0x10a456d90 def test_add(self): 测试加法功能。 calc Calculator() result calc.add(2, 3) # 使用简单的assert语句进行断言 assert result 6 E assert 5 6 tests/test_calculator.py:12: AssertionError short test summary info FAILED tests/test_calculator.py::TestCalculator::test_add - assert 5 6 1 failed, 4 passed in 0.05s 错误信息非常友好它直接告诉你哪个文件、哪个类、哪个测试失败了并且用标出了出错的行下面显示了断言两边的值5 6。最下面还有一个简短的总结。这就是pytest的魅力之一强大的失败信息报告。注意事项pytest的断言之所以强大是因为它重写了Python内置的assert语句能智能地展示断言两边的值。你不需要再记忆unittest里那些assertEqual、assertTrue等五花八门的方法了一个assert走天下。但这也意味着在pytest中不要用assert来做一些有副作用的事情比如assert my_list.pop()因为断言失败时pytest会为了展示信息而重新评估表达式可能导致意外行为。4. pytest的核心功能与高级用法实战通过了基础测试我们来深入pytest的几个核心功能这些是构建健壮测试套件的关键。4.1 夹具Fixtures管理测试依赖和状态夹具是pytest最强大、最特色的功能。你可以把它理解为测试的“脚手架”或“背景设置”。它的主要作用是提供可复用的、预配置的上下文或对象避免在每个测试函数中重复编写相同的准备和清理代码。一个经典场景数据库连接。很多测试需要先连接数据库插入一些测试数据测试完后再清理数据关闭连接。用夹具可以优雅地实现。让我们在tests/conftest.py中定义一个简单的夹具import pytest # 使用pytest.fixture装饰器定义一个夹具 pytest.fixture def calculator(): 提供一个初始化好的Calculator实例。 print(\n夹具执行创建Calculator实例) from my_package.calculator import Calculator return Calculator() # 这是“准备”阶段返回的对象会注入给测试函数 # 一个更复杂的夹具带有清理操作 pytest.fixture def temporary_file(tmp_path): 创建一个临时文件并在测试后自动清理。 # tmp_path是pytest内置的夹具提供一个临时目录路径对象 file_path tmp_path / test_data.txt file_path.write_text(Hello, pytest!) print(f\n夹具执行创建临时文件 {file_path}) yield file_path # 将文件路径提供给测试函数使用 # yield之后的代码是“清理”阶段无论测试成功还是失败都会执行 print(f\n夹具执行清理临时文件 {file_path}) # 因为tmp_path是临时目录测试结束后整个目录会被自动删除所以这里不需要手动删除文件。 # 这里打印只是为了演示清理阶段确实执行了。然后在测试文件中使用它们# tests/test_with_fixture.py import pytest class TestWithFixture: # 测试函数通过参数名来请求夹具。pytest会自动匹配并注入。 def test_add_with_fixture(self, calculator): 使用calculator夹具. # calculator参数就是上面夹具返回的那个Calculator实例 assert calculator.add(1, 2) 3 # 我们不需要在测试函数内部实例化Calculator代码更简洁。 def test_file_operations(self, temporary_file): 使用temporary_file夹具. # temporary_file就是夹具yield出来的Path对象 content temporary_file.read_text() assert content Hello, pytest! # 测试结束后夹具会自动执行清理打印信息 # 一个测试函数可以使用多个夹具 def test_combination(self, calculator, temporary_file): 同时使用多个夹具. assert calculator.multiply(2, 3) 6 assert temporary_file.exists()运行测试你会看到夹具中print的信息在控制台输出清晰地展示了夹具“准备-注入-清理”的生命周期。夹具的作用域pytest.fixture默认的作用域是function即每个测试函数都会执行一次。你还可以指定其他作用域scopefunction默认每个测试函数运行一次。scopeclass每个测试类运行一次。scopemodule每个测试模块文件运行一次。scopesession整个测试会话一次pytest命令运行一次。对于创建成本很高的资源如数据库连接池、启动一个外部服务使用session或module作用域能极大提升测试速度。实操心得夹具是消除测试代码中“重复造轮子”的利器。但要注意夹具也不宜过度使用或设计得过于复杂。如果一个夹具做了太多事情比如同时初始化数据库、创建用户、准备配置文件它会变得难以理解和维护。遵循“单一职责”原则定义多个小而专的夹具然后在测试中按需组合它们。4.2 参数化测试用一组数据测试多种情况我们经常需要用多组不同的输入输出数据来测试同一个功能。比如测试加法我们想验证(1,1,2),(0,5,5),(-1, -1, -2)等多种情况。如果为每组数据写一个测试函数代码会非常冗余。pytest的pytest.mark.parametrize装饰器就是为此而生。# tests/test_parametrize.py import pytest from my_package.calculator import Calculator # 为测试函数添加参数化装饰器 # 第一个参数是参数字符串用逗号分隔对应测试函数的参数名。 # 第二个参数是一个可迭代对象列表、元组其中每个元素是一组测试数据。 pytest.mark.parametrize( a, b, expected, [ (1, 1, 2), (0, 5, 5), (-1, -1, -2), (2.5, 3.5, 6.0), ] ) def test_add_parametrized(a, b, expected): 使用多组数据测试加法。 calc Calculator() assert calc.add(a, b) expected # 更复杂的参数化测试异常情况 pytest.mark.parametrize( a, b, expected_exception, expected_message, [ (10, 0, ValueError, 除数不能为零), (0, 0, ValueError, 除数不能为零), # 即使被除数是0除数为0也应报错 ] ) def test_divide_by_zero_parametrized(a, b, expected_exception, expected_message): 参数化测试异常。 calc Calculator() with pytest.raises(expected_exception) as exc_info: calc.divide(a, b) assert str(exc_info.value) expected_message运行参数化测试时pytest会为每一组数据生成一个独立的测试用例并在报告中分别显示。如果某一组数据失败了你能精确地知道是哪一组输入出的问题。4.3 标记Marking分类与选择测试用例当测试套件变得庞大你可能只想运行某一类测试比如慢速测试、集成测试、或者针对某个特定模块的测试。pytest的标记系统可以给测试函数打上“标签”。首先最好在项目根目录或tests目录下创建一个pytest.ini文件如果没用pyproject.toml配置的话来注册自定义的标记避免拼写错误警告# pytest.ini [pytest] markers slow: 标记运行缓慢的测试。 integration: 标记需要外部依赖如数据库、API的集成测试。 smoke: 冒烟测试用于快速验证核心功能。然后在测试中使用标记# tests/test_marking.py import pytest import time from my_package.calculator import Calculator def test_fast_addition(): 这是一个快速测试。 calc Calculator() assert calc.add(1, 1) 2 pytest.mark.slow # 使用自定义的slow标记 def test_slow_operation(): 模拟一个运行缓慢的测试。 time.sleep(2) # 模拟耗时操作 calc Calculator() assert calc.add(100, 200) 300 pytest.mark.integration def test_with_external_service(): 模拟一个需要外部服务的集成测试。 # 这里假设有一些调用外部API或数据库的代码 # 如果外部服务不可用这个测试应该跳过或失败 print(调用外部服务...) # 为了示例我们假设它总是通过 assert True # 可以同时打多个标记 pytest.mark.slow pytest.mark.integration def test_slow_integration(): 既慢又是集成测试。 time.sleep(1) assert True现在你可以通过命令行选择性地运行测试# 只运行标记为smoke的测试 pytest -m smoke # 运行除了slow以外的所有测试 pytest -m not slow # 运行integration或smoke的测试 pytest -m integration or smoke注意事项标记是一个非常灵活的功能但不要滥用。标记体系应该简单、一致并且在整个团队内达成共识。否则每个人定义的标记都不一样反而会增加管理成本。通常“slow”、“integration”、“smoke”这几个标记就足够应对大多数场景了。5. 测试覆盖率与报告生成写了测试我们怎么知道测试得够不够全面呢测试覆盖率是一个重要的量化指标。它告诉我们有多少比例的代码被测试执行过。pytest-cov插件就是干这个的。5.1 生成并解读覆盖率报告运行测试并生成覆盖率报告非常简单# 基本命令在终端输出简略报告 pytest --covmy_package tests/ # 更详细的终端报告显示哪些行没有被覆盖 pytest --covmy_package --cov-reportterm-missing tests/ # 生成HTML报告可视化效果更好 pytest --covmy_package --cov-reporthtml tests/运行--cov-reporthtml后会在项目根目录生成一个htmlcov文件夹。打开里面的index.html你会看到一个类似下图的网页报告这里用文字描述报告内容 报告会展示总体覆盖率比如“TOTAL 85%”。每个文件的覆盖率包括语句覆盖率Statements、分支覆盖率Branch如果代码有if/else等条件判断、函数覆盖率Funcs和行覆盖率Lines。点击文件名可以进入该文件的详情页用不同颜色高亮显示哪些行被覆盖了绿色哪些行没被覆盖红色哪些行是排除的如空行、注释通常是灰色。5.2 如何提高覆盖率看到红色未覆盖的代码行就是我们需要补充测试用例的地方。通常未覆盖的代码包括错误处理分支比如我们divide方法中的if b 0:分支我们已经在test_divide_by_zero中覆盖了。边界条件比如输入为空列表、极大值、极小值等。难以触发的条件某些复杂的条件组合。简单的getter/setter或属性有时工具会报告这些行未覆盖但如果你认为测试价值不大可以通过配置忽略它们。不要盲目追求100%覆盖率这是一个非常重要的原则。100%覆盖率是一个美好的理想但追求它可能成本极高且得不偿失。有些代码如简单的数据模型、框架自动生成的代码测试价值很低有些错误处理分支如内存耗尽、网络瞬间断开在单元测试中极难模拟。更务实的做法是关注核心业务逻辑和复杂算法的覆盖率确保它们被充分测试。覆盖主要的正常路径和重要的异常路径。利用覆盖率报告作为发现测试盲点的工具而不是一个必须达成的KPI。85%-95%的覆盖率对于大多数项目来说已经是非常好的水平了。实操心得将覆盖率检查集成到你的CI/CD流程中比如GitHub Actions, GitLab CI。可以设置一个覆盖率阈值例如80%如果新提交的代码导致覆盖率低于这个阈值则CI失败。这能有效地防止测试代码的退化确保测试随着功能开发同步进行。6. 常见问题与排查技巧实录在实际使用pytest的过程中你肯定会遇到一些“坑”。这里我记录了几个最常见的问题和解决方法。6.1 导入错误ImportError问题描述运行pytest时报错ModuleNotFoundError: No module named ‘my_package‘。原因分析这是新手遇到最多的问题。pytest运行时会改变Python的模块查找路径sys.path。如果你的项目不是以可安装包的形式组织或者路径设置不对pytest就找不到你的源代码模块。解决方案使用src目录布局如前文所述将代码放在src/my_package下并在pyproject.toml中配置pythonpath [“src”]。这是最推荐、最一劳永逸的方法。在conftest.py中修改sys.path不推荐# tests/conftest.py import sys from pathlib import Path sys.path.insert(0, str(Path(__file__).parent.parent / src))这种方法虽然能工作但属于“魔改”系统路径可能会带来意想不到的副作用尤其是在复杂的项目结构中。以开发模式安装你的包在项目根目录运行pip install -e .。这会在你的环境中创建一个指向当前目录的链接让Python像安装了的包一样识别你的代码。然后pytest就能正常导入了。这对于最终要打包分发的项目是标准流程。6.2 测试发现失败问题描述运行pytest它说collected 0 items没有找到任何测试。原因分析pytest默认的测试发现规则是递归查找当前目录及其子目录下所有名为test_*.py或*_test.py的文件并收集其中以test_开头的函数和以Test开头的类中的test_方法。排查步骤检查文件名和函数名确保测试文件以test_开头或结尾测试函数/方法以test_开头。检查__init__.py文件如果你的tests目录是一个包里面有__init__.py但你的测试文件里没有__init__.py或者pytest的配置有问题有时会影响发现。通常tests目录下放不放__init__.py都可以pytest都能处理。如果放了确保它可能是一个空文件。使用pytest --collect-only命令这个命令不会运行测试只会展示pytest发现了哪些测试项。通过它你可以清楚地看到测试收集的结果定位是哪个环节出了问题。检查pytest.ini或pyproject.toml配置确认里面的testpaths配置是否正确指向了你的测试目录。6.3 夹具Fixture作用域理解错误导致状态污染问题描述测试A修改了某个由夹具提供的对象比如一个列表导致测试B运行时的初始状态不是预期的测试B因此失败。原因分析夹具默认的作用域是function。但如果夹具返回的是一个可变对象如列表、字典、自定义类的实例并且你在测试中修改了它那么在同一个作用域内后续的测试看到的将是修改后的对象。对于function作用域由于每个测试都会重新执行夹具函数所以通常没问题。但如果你错误地使用了scopeclass或scopemodule并且修改了夹具返回的对象就会导致测试间状态污染。解决方案优先返回不可变对象或数据的深拷贝在夹具中尽量返回数字、字符串、元组等不可变对象。如果需要返回可变对象考虑返回它的深拷贝copy.deepcopy()。import copy pytest.fixture def complex_data(): data {key: [mutable, list]} return copy.deepcopy(data) # 返回深拷贝每个测试获得独立副本谨慎使用scope除非确有必要如初始化数据库连接池否则尽量使用默认的function作用域。在测试中避免修改夹具提供的对象这是一个编码习惯。将夹具返回的对象视为“只读”的测试上下文如果需要不同的数据应该通过参数化测试来实现或者定义不同的夹具。6.4 测试执行顺序与依赖问题描述测试B依赖于测试A先执行并产生的某个结果或状态。根本原因单元测试应该是相互独立、没有顺序依赖的这是单元测试的一个核心原则。一个测试的成功或失败不应影响其他测试。如果你的测试之间存在依赖说明测试设计有问题可能引入了共享的全局状态。解决方案重构测试消除依赖每个测试都应该自己准备所需的所有数据通常通过夹具。如果多个测试需要相同的数据定义一个夹具来提供但确保夹具每次提供的是干净、独立的数据副本。绝对不要依赖测试执行顺序pytest默认的测试发现顺序可能是按文件名、函数名的字母顺序但这个顺序是不保证的未来pytest版本或不同的发现插件可能会改变它。永远不要假设测试A会在测试B之前运行。如果真有集成测试需要顺序对于少数需要按流程执行的集成测试或端到端测试E2E可以考虑将它们放在一个单独的测试类或模块中并使用pytest-order等插件来显式定义顺序。但请明确区分这是集成测试不是单元测试。6.5 慢速测试拖累开发反馈问题描述测试套件中有一些访问数据库、调用外部API的慢速测试每次运行全部测试都要等很久打断了开发的流畅性。解决方案使用标记Mark分类如前所述用pytest.mark.slow或pytest.mark.integration标记这些慢速测试。日常开发只运行快速测试在本地开发时使用pytest -m “not slow”来跳过慢速测试快速获得反馈。在CI/CD中运行全部测试在持续集成服务器上配置任务运行所有测试包括慢速的确保每次提交都经过完整验证。Mock外部依赖对于单元测试核心原则是“隔离”。应该使用unittest.mock模块Python标准库来模拟Mock数据库查询、网络请求等外部操作。这样测试就能快速运行且不依赖外部环境的状态。from unittest.mock import Mock, patch import requests def test_fetch_data(mocker): # mocker是pytest-mock插件提供的夹具 # 模拟requests.get返回一个特定的响应而不是真正发起网络请求 mock_response Mock() mock_response.json.return_value {key: value} mock_response.status_code 200 with patch(requests.get, return_valuemock_response): # 在这里调用你的函数它会使用模拟的requests.get result my_module.fetch_data_from_api() assert result {key: value}使用Mock可以将一个需要2秒的网络请求测试变成只需要2毫秒的本地调用测试。7. 将测试集成到开发工作流写测试不是一次性任务而是需要融入日常开发习惯。下面是一些让测试变得“自然”的建议。7.1 在IDE中运行测试现代IDE如VS Code, PyCharm都对pytest有很好的集成。VS Code安装Python扩展后测试资源管理器会自动发现pytest测试。你可以在侧边栏点击运行单个测试、单个测试文件、或者所有测试。点击测试结果中的失败行还能直接跳转到对应的代码。PyCharm在设置中指定测试运行器为pytest然后就可以右键点击文件或目录来运行测试了同样有非常直观的图形化结果展示。在IDE中运行测试的反馈循环极短是进行测试驱动开发TDD的利器。7.2 配置预提交钩子Pre-commit Hook你可以配置Git的pre-commit钩子在每次执行git commit之前自动运行你的测试套件至少是快速测试。如果测试失败则中止提交。这能防止有问题的代码进入版本库。首先安装pre-commit框架pip install pre-commit。 然后在项目根目录创建.pre-commit-config.yaml文件repos: - repo: local hooks: - id: pytest name: Run Fast Tests entry: bash -c cd /path/to/your/project source venv/bin/activate pytest -m not slow language: system pass_filenames: false always_run: true stages: [commit]然后运行pre-commit install来安装钩子。之后每次git commit都会自动触发测试。7.3 持续集成CI流水线在团队协作中必须有一个中心化的地方来运行所有测试包括慢速和集成测试。这就是CI服务器的职责。流行的选择有GitHub Actions、GitLab CI、Jenkins等。这里是一个GitHub Actions工作流的简单示例放在.github/workflows/test.ymlname: Python Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest strategy: matrix: python-version: [3.8, 3.9, 3.10] # 测试多个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 pytest pytest-cov pip install -e . # 以开发模式安装当前包 - name: Test with pytest run: | pytest --covmy_package --cov-reportxml - name: Upload coverage to Codecov uses: codecov/codecov-actionv3 with: file: ./coverage.xml这个工作流会在每次推送代码或创建拉取请求时在多个Python版本下运行测试计算覆盖率并上传到Codecov等服务。这样代码审查者就能在合并请求中直观地看到测试状态和覆盖率变化。从在终端里敲下第一个pytest命令到搭建起一个包含夹具、参数化、标记、覆盖率报告并能集成到CI/CD的完整测试体系这个过程本身也是对代码质量意识的一次升级。测试不再是负担而是一种让你编码时更加自信、重构时更加大胆的保障。它迫使你思考接口设计、边界条件和错误处理最终产出的不仅仅是经过验证的代码更是清晰、模块化、可维护的软件设计。