高天借coverage.py规范Python测试要求单元测试覆盖率达100%

码农高天

单元测试只有达到100%覆盖率才能让未测新代码无所遁形，浮动指标只会掩盖漏洞，极少数不可测分支应显式标记豁免。

AI-assisted summary of 【python】使用coveragepy计算单元测试的覆盖率 — original source. Check the original for full context.

Source published: 2024-06-15

Key ideas

行覆盖率是量化评估单元测试质量的基础指标，在 Python 生态中 coverage.py 是事实上的首选核心工具。 (0:00)
使用 coverage run 收集数据后，通过 coverage report -m 终端输出或 coverage html 可视化页面可快速定位未执行的具体代码行。 (2:30)
针对多模块或第三方依赖代码，可通过 .coveragerc 配置文件设定 --source 与 --omit 过滤规则，并无缝集成 GitHub Actions 与 Codecov 自动化流水线。 (5:00)
追求 100% 覆盖率是感知新增代码未测漏洞的唯一质变标准，确实无法测试的分支应显式标注 # pragma: no cover 进行排除。 (6:20)

Detailed notes

## Background 该视频由 YouTube 频道“码农高天”于 2024 年 6 月 15 日发布。视频简介指出，单元测试质量的黄金标准之一便是覆盖率，本期内容主要介绍如何使用 coverage.py 这一工具来计算并优化 Python 单元测试的覆盖率。

## TL;DR 视频首先通过简单的素数判断函数展示了行覆盖率的概念，并演示了如何使用 coverage.py 进行测试数据采集、终端行号缺失查看以及生成交互式 HTML 可视化报告。随后针对实际开源项目，介绍了利用 --source 和 --omit 过滤无关代码，并建议将这些规则固化在 .coveragerc 配置文件中，配合 GitHub Actions 与 Codecov 实现云端自动化流水线。最后，作者探讨了测试哲学的终极问题，坚决主张项目应追求 100% 的覆盖率质变，并对极少数无法触达的特殊分支使用 # pragma: no cover 进行显式标注豁免。

## Atmosphere & style 整期视频呈现出清晰严谨、条理分明且务实的工程师技术分享风格。高天的讲解平实质朴却充满笃定，从最基础的 CLI 操作层层递进到工程化 CI/CD 配置，既有手把手教学的细致，又有直面开发痛点的经验之谈。在探讨‘覆盖率到底要多少’时，语气从容但观点极具原则性与穿透力，让观众在掌握实用技能的同时，也能深切感受到专业开发者对代码质量与工程纪律的敬畏之心。

## Bulletin - [00:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=0s) 行覆盖率是量化评估单元测试质量的基础指标，在 Python 生态中 coverage.py 是事实上的首选核心工具。 - [02:30](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=150s) 使用 coverage run 收集数据后，通过 coverage report -m 终端输出或 coverage html 可视化页面可快速定位未执行的具体代码行。 - [05:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=300s) 针对多模块或第三方依赖代码，可通过 .coveragerc 配置文件设定 --source 与 --omit 过滤规则，并无缝集成 GitHub Actions 与 Codecov 自动化流水线。 - [06:20](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=380s) 追求 100% 覆盖率是感知新增代码未测漏洞的唯一质变标准，确实无法测试的分支应显式标注 # pragma: no cover 进行排除。

## Key takeaways - [00:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=0s) 单元测试的好坏可以通过代码覆盖率来客观量化，最基本的形式是行覆盖率（Line Coverage）。 - [00:25](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=25s) 在 Python 生态中，测试代码覆盖率的工具首选为 coverage.py，在同类领域基本没有对手。 - [01:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=60s) coverage.py 的工作流程分为两步：先通过 coverage run 运行测试生成原始数据，再通过 coverage report 进行结果分析。 - [01:30](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=90s) 命令行参数 -m（--show-missing）能够在终端中精确高亮未被测试执行的具体源码行号。 - [02:30](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=150s) 执行 coverage html 会生成交互式 HTML 报告，使用红绿色块直观展示每一行代码的覆盖情况。 - [03:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=180s) 测试已安装库或开源包时，默认只会统计测试目录，需通过 --source 参数明确指定被测的目标源码模块。 - [03:50](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=230s) 对于项目中混入的第三方开源代码或非核心文件，可以使用 --omit 过滤参数将其排除在覆盖率统计之外。 - [05:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=300s) 使用 INI 格式的 .coveragerc 配置文件可以固化 source 和 omit 等长参数，避免每次手动拼写命令。 - [05:30](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=330s) 在 CI/CD 中结合 GitHub Actions 与免费的 Codecov 服务，可实现 PR 提交时的自动覆盖率报告与可视化追踪。 - [06:20](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=380s) 覆盖率只有达到 100% 才是质变，允许低于 100% 会让人陷入不断妥协的滑坡谬误。 - [06:45](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=405s) 维持 100% 覆盖率的核心价值在于报警机制：一旦提交了未覆盖的新代码，总指标会立刻跌破 100% 并引起注意。 - [07:15](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=435s) 对于现实中确实无法覆盖的防御性分支，必须使用 # pragma: no cover 显式注释排除，而非直接调低全局覆盖率要求。

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=0s) 单元测试的量化指标与 coverage.py 入门

许多刚开始接触测试的开发者常常会陷入一个困惑：怎么判断自己的单元测试写得好不好、测得够不够？对于这个问题，最基础、最直观且最有效的量化评价指标就是单元测试的“覆盖率”（Coverage）。所谓覆盖率，概念非常简单直白，就是编写的测试代码在执行时到底实际运行了多少业务逻辑代码。在各类覆盖率指标中，最基本的就是“行覆盖率”（Line Coverage），即源码中有多少行在测试运行时被真正执行了。

为了直观展示这一过程，高天举了一个简短的素数判断函数 `is_prime` 作为示例。该函数仅有四行代码，实现非常简单；同时编写了一个单元测试用例，用来断言 3 是素数。此时便引出了核心问题：仅仅测试了数字 3，这个测试到底算不算充分？如果不充分，凭什么说它不充分？空口无凭的争论没有意义，这就需要引入可量化的覆盖率工具。在 Python 生态中，测试代码覆盖率最常用的工具就是 `coverage.py`（包名写作 `coverage`），高天直言：“在这个领域啊他基本上没有任何对手。”

使用 `coverage.py` 计算覆盖率主要分为两个阶段：第一步是运行测试以产生覆盖率原始数据，第二步是对产生的数据进行统计与总结。平时使用 Python 自带测试框架运行时，通常执行 `python -m unittest`；而要计算覆盖率，只需将开头的 `python` 替换为 `coverage run` 命令，即执行 `coverage run -m unittest`。运行之后，除了正常的测试输出外，当前目录下还会多出一个二进制格式的 `.coverage` 数据文件。要查看结果，可以直接使用命令行工具 `coverage report`。在示例中，包含 5 行代码的文件有一行未被运行，覆盖率为 80%。通过追加 `-m`（即 `--show-missing`）参数执行 `coverage report -m`，终端会直接指出未覆盖的具体行号（第 4 行，即 `return False` 分支）。原来测试用例只覆盖了结果为 `True` 的素数 3，并没有测试返回 `False` 的非素数情况；随后补上针对数字 4 的测试用例并重新运行，覆盖率便达到了 100%。

```mermaid flowchart LR accTitle: coverage.py 基础工作流 accDescr: 展示从执行测试产生数据到终端汇报覆盖率的步骤流程

A["业务代码与单元测试"] --> B["coverage run -m unittest"] B --> C[".coverage 二进制数据"] C --> D["coverage report -m"] D --> E["定位未覆盖代码行并补齐测试"] ```

- **安装命令**：`pip install coverage` - **运行并记录覆盖率**：`coverage run -m unittest` - **命令行查看概要**：`coverage report` - **显示未覆盖行号**：`coverage report -m`（`Missing` 列明确标注未执行的具体行）

---

[02:30](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=150s) 可视化 HTML 报告与多模块源码覆盖

虽然命令行终端快速直观，但许多开发者并不喜欢粗糙的 CLI 界面，特别是当项目规模变大、未覆盖的代码行数较多时，一行行对照源码找缺失会非常繁琐。为此，`coverage.py` 提供了可视化的 HTML 报告生成功能。只需在终端执行 `coverage html`，工具就会读取 `.coverage` 数据并在本地生成一个名为 `htmlcov` 的文件夹。开发者可以在该目录下启动一个简易的本地 HTTP 服务器并在浏览器中查看交互式页面。在 HTML 页面中，不仅有各个文件的总览，点击具体文件名还能直接阅读源代码——被测试覆盖的代码行会高亮标记为绿色，而未覆盖的代码行则显示为醒目的红色，缺失分支一目了然。

当面对实际的开源库或复杂项目时，覆盖率的统计往往会遇到新的挑战。高天以自己的开源项目 `objprint` 为例：如果直接执行 `coverage run -m unittest` 然后运行报告，会惊讶地发现报告里全是测试文件本身（`tests/`），安装好的核心库源码根本没有出现，实际上变成了“在测试我们测试的覆盖率”。这是因为 `coverage` 默认不会自动去统计环境中已安装库的源代码覆盖率。要解决这个问题，必须加上 `--source` 参数，明确指定需要跟踪统计的目标库名称（例如 `--source objprint`）。

明确指定源码路径后，新的问题又随之出现：报告中可能会包含一些覆盖率极低的文件。这通常是因为项目中引用或打包了别人的开源第三方代码。既然是第三方代码，开发者通常不需要为其编写测试或关心其覆盖率。如果不希望这些外来文件拉低整体指标，可以在执行覆盖率收集时通过 `--omit` 参数将其排除，过滤掉符合特定通配符规则的源码文件，让最终报告只聚焦于自己亲手编写的核心业务逻辑。

- **生成网页端报告**：`coverage html`（默认在当前目录输出 `htmlcov/`） - **指定被测源码模块**：`coverage run --source <package_name> -m unittest` - **忽略特定文件或目录**：`coverage run --omit="<glob_pattern>"...`

---

[05:00](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=300s) 配置文件 .coveragerc 与 GitHub Actions / Codecov 自动化

每次运行测试都要手动输入 `--source` 和 `--omit` 等又长又难记的命令行参数，在日常开发中十分容易出错且令人厌烦。针对这一痛点，高天介绍了 `coverage.py` 的配置文件 `.coveragerc`。`.coveragerc` 本质上是一个 INI 格式的配置文件，开发者可以在其中将需要忽略的文件路径、源代码目标目录等参数提前固化下来。配置完成后，在当前目录下直接执行干净简短的 `coverage run -m unittest`，工具就会自动读取规则并排除无关文件，无需每次在终端手动拼写长参数。

但在本地手动执行测试和生成报告，对于持续迭代的项目来说依然不够省心。为了让团队和维护者能在代码提交或发起 Pull Request 时自动获得反馈，最推荐的做法是将覆盖率集成到 CI/CD 流水线中。高天推荐利用 GitHub Actions 配合在线平台 Codecov 实现完全自动化的覆盖率看板：在 GitHub Actions 的工作流中运行测试并生成 XML 格式的覆盖率报告，随后使用官方提供的 `codecov/codecov-action` 将报告推送到 Codecov。Codecov 会自动生成美观的覆盖率曲线图、提交对比以及具体到文件的代码高亮。对于开源项目而言，Codecov 平台完全免费，高天提到自己目前所有的 Python 开源项目都在依靠该方案自动生成覆盖率报告。

```mermaid flowchart TD accTitle: GitHub Actions 与 Codecov 自动化流程 accDescr: 展示从 Git 提交到 Codecov 报告生成的 CI 自动化流程

subgraph Local["本地开发配置"] RC[".coveragerc 配置文件"] end

subgraph CI["GitHub Actions 流水线"] RunTest["运行测试并生成 XML 报告"] Upload["codecov-action 上传报告"] end

subgraph Cloud["Codecov 云端服务"] Dashboard["生成可视化覆盖率图表与 PR 状态检查"] end

RC -.->|"读取规则"| RunTest RunTest --> Upload Upload --> Dashboard ```

- **配置文件规范**：使用 `.coveragerc` 保存 `omit`、`source` 等自定义规则。 - **CI 流水线配置**：在 GitHub Actions 中跑测试并生成标准覆盖率报告文件（如 XML）。 - **云端集成**：开源项目接入 Codecov 完全免费，自动在 Pull Request 和主页展示徽章与覆盖率明细。

---

[06:20](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=380s) 覆盖率究竟多少才算够？100% 与 pragma: no cover

关于测试覆盖率，业界和开发者群体中最常被讨论的一个争议话题就是：“覆盖率到底达到多少百分比才算够？”有人认为 80% 足矣，有人认为 90% 即可。针对这个终极问题，高天给出了极其明确且坚定的答案。

> “对我个人而言，这个数是百分之百，因为只有百分之百是质变，剩下的都是量变。” —— 码农高天

高天进一步解释了追求 100% 的底层逻辑：如果心理底线退让到 95%，那随之而来的妥协就会没完没了——为什么 90% 不行？为什么 85% 不行？为什么 80% 就不行呢？更关键的原因在于对新代码的感知力：只有当一个项目的覆盖率常态化维持在 100% 时，一旦新增的代码没有编写测试，整体覆盖率就会瞬间跌破 100%，从而立刻引起开发者的警觉并暴露问题。反之，如果项目长期处于 80% 或 90% 的浮动状态，随着总代码行数不断增减，百分比数字本身就会上下波动，开发者根本无法察觉新写的代码到底有没有被测试覆盖。因此，对于个人和开源项目而言，100% 才是唯一严谨的目标。

当然，在实际工程实现中，确实存在某些极特殊分支或防御性代码在单元测试环境下极其难以触达。高天强调，对待这种情况绝不能心存侥幸或者简单妥协，而是应当采用显式标注机制：在对应的代码块后添加注释注释标记 `# pragma: no cover`。这个标记会明确告知 `coverage.py` 该代码块属于被豁免统计的区域。高天总结道，原则必须是“所有覆盖不到的代码你都要明确地标记，所有能覆盖到的代码全都覆盖”；如果仅仅是因为偷懒不想写测试就到处乱标无须覆盖，那么统计覆盖率本身也就完全失去了意义。

- **覆盖率哲学**：100% 是唯一的质变；低于 100% 会掩盖新代码未测的漏洞。 - **免测标注标记**：使用 `# pragma: no cover` 显式排除真正无法测试的边缘分支，保持全局 100% 可控。

## Notable quotes > [06:20](https://www.youtube.com/watch?v=5Md_3ZeuYPc&t=380s) 所有覆盖不到的代码你都要明确地标记，所有能覆盖到的代码全都覆盖 — 码农高天

## Mentioned 码农高天, Python, coverage.py, unittest, objprint, GitHub Actions, Codecov, codecov-action

## Video description 判断单元测试质量的一个黄金标准就是覆盖率，我们来介绍一下如何使用coveragepy这个工具来计算单元测试的覆盖率！

[Source](https://www.youtube.com/watch?v=5Md_3ZeuYPc)

中文简报

高天借coverage.py规范Python测试要求单元测试覆盖率达100% 单元测试只有达到100%覆盖率才能让未测新代码无所遁形，浮动指标只会掩盖漏洞，极少数不可测分支应显式标记豁免。视频首先通过简单的素数判断函数展示了行覆盖率的概念，并演示了如何使用 coverage.py 进行测试数据采集、终端行号缺失查看以及生成交互式 HTML 可视化报告。随后针对实际开源项目，介绍了利用 --source 和 --omit 过滤无关代码，并建议将这些规则固化在 .coveragerc 配置文件中，配合 GitHub Actions 与 Codecov 实现云端自动化流水线。最后，作者探讨了测试哲学的终极问题，坚决主张项目应追求 100% 的覆盖率质变，并对极少数无法触达的特殊分支使用 # pragma: no cover 进行显式标注豁免。行覆盖率是量化评估单元测试质量的基础指标，在 Python 生态中 coverage.py 是事实上的首选核心工具。 (0:00) 使用 coverage run 收集数据后，通过 coverage report -m 终端输出或 coverage html 可视化页面可快速定位未执行的具体代码行。 (2:30) 针对多模块或第三方依赖代码，可通过 .coveragerc 配置文件设定 --source 与 --omit 过滤规则，并无缝集成 GitHub Actions 与 Codecov 自动化流水线。 (5:00) 追求 100% 覆盖率是感知新增代码未测漏洞的唯一质变标准，确实无法测试的分支应显式标注 # pragma: no cover 进行排除。 (6:20)

Reading summary

码农高天指出，代码行覆盖率是评估单元测试充分性的核心量化指标，在 Python 生态中应首选 coverage.py 配合 CI 流水线实施质量监控。他主张开发者应将 100% 覆盖率作为质变目标，并通过显式标记豁免特殊代码，以确保任何未测的新增代码能被即时察觉。量化测试充分性与 coverage.py 基础命令 (0:00) 许多开发者难以客观评估单元测试是否完备，覆盖率（尤其是行覆盖率）提供了直观的量化标准。针对简单的素数判断函数 `is_prime`，单一断言无法覆盖全部逻辑分支；借助 Python 主流工具 `coverage.py`，开发者能够精确统计代码执行范围。执行 `coverage run -m unittest` 会在运行测试的同时生成二进制 `.coverage` 文件，随后通过 `coverage report` 可查看整体百分比，追加 `-m` 参数更能直接列出未覆盖的具体行号，指引开发者精准补充测试用例以消除盲区。 HTML 可视化与复杂项目模块过滤 (2:30) 在代码量较大的工程中，纯命令行排查效率较低。通过运行 `coverage html`，工具会在 `htmlcov` 目录下生成静态网页，以红绿两色直观高亮标注源码的覆盖与缺失状态。面对实际项目如 `objprint` 时，默认命令可能仅统计测试代码本身，此时需使用 `--source` 参数显式指定被测目标模块。若项目中包含无须开发者维护的第三方源码，可通过 `--omit` 配合通配符规则将其剔除，防止无关文件拉低覆盖率统计结果。配置文件固化与 GitHub Actions 自动化集成 (5:00) 频繁在终端输入长参数容易出错，开发者应将 `source` 与 `omit` 等规则写入 `.coveragerc` 配置文件，使后续测试命令恢复简洁。针对团队协作与持续迭代，高天建议将覆盖测试移至 GitHub Actions 等 CI/CD 流水线，在测试完成后生成 XML 报告，并通过 `codecov/codecov-action` 自动推送到开源免费的 Codecov 平台。该方案能自动绘制覆盖率趋势曲线并在 Pull Request 中提供状态检查与代码高亮。追求 100% 覆盖率的逻辑与显式豁免机制 (6:20) 高天认为覆盖率只有达到 100% 才是“质变”，允许 80% 或 90% 的浮动会导致心理底线不断退让；更重要的是，非 100% 的浮动状态会掩盖新提交代码缺乏测试的问题，而维持 100% 基线能让任何漏测立即暴露。针对单元测试极难触达的防御性代码或边缘分支，不应降低整体指标，而应在源码中添加 `# pragma: no cover` 注释显式告知工具豁免统计。这种做法既保证了全局覆盖率的严肃性，又对特殊代码行保留了明确记录。测试覆盖率的核心价值在于通过严格的规则约束代码质量，维持 100% 的常态化基线能让开发盲区即时暴露，但该实践要求团队对 `# pragma: no cover` 保持谨慎克制，防止滥用标记规避编写测试的责任。

Source quotes

[6:20] 码农高天: 所有覆盖不到的代码你都要明确地标记，所有能覆盖到的代码全都覆盖

Original transcript

[0:00] 最近有粉丝朋友问了我一个问题啊说怎么判断我的单元测试做的好不好那对于很多刚开始写测试的人来说呢这确实是一个问题他可能不太能够判断我的测试是不是写够了那在这里呢我就给大家介绍一个最基础最直观最有效的评价单元测试质量的方法就是看这个单元测试的覆盖率覆盖率这个概念很容易理解就是我写的测试到底运行了多少我写的代码那么今天我们讲一下覆盖率中最基础的叫做行覆盖率也就是说我写的代码里面有多少行被运行了比如大家看左边我们写了一个is'函数来判断一个数是不是素数这个函数里面呢一共只有四行非常简单对吧我们也不详细介绍它的实现然后同时呢我们还写了一个测试这个测试里呢我们写了一个test case我们要确认三是素数好那现在问题来了我写的测试足够了吗如果你认为不够,凭什么不够?在这种情况下我们就可以引入可量化的这个覆盖率来解决这个问题当然了想计算覆盖率我们需要工具在python中最常用的测覆盖率的工具就是coverage pi在这个领域啊他基本上没有任何对手我们首先来安装CoveragePi,PIP install Coverage我这里是有cached版本如果没有cached版本的话就会下载一下使用coverage派一共分为两步第一步产生覆盖数据第二步总结覆盖数据首先我们回忆一下,我们写的这个unit test是如何运行的?如果大家不记得了可以去翻我之前的视频我们运行测试的方法就是python-m unit test当然在这里我们只有一个test对吧他说运行了一个test怎么得到这个 unit test 覆盖率呢我们就不用 Python 来运行 unit test 了而是用 coverage run 这个命令coverage是我们刚刚下载的那个酷而run是一个子命令代表跑一个程序来产生覆盖率数据这里的意思就是跑一下python-munitas然后看看覆盖率用coverage run来运行和用python来运行得到的结果应该是一样的但是我们可以看到产生了一个新的点coverage文件这个文件里以二进制的形式保存着我们覆盖率的数据那怎么读取这个覆盖率数据呢最简单的我们可以用 command line 命令 coverage report这里就看到了我们的覆盖率数据对不对我们写的mymath这个文件一共有五行其中有一行没有被覆盖到覆盖率是80%那我怎么看是哪行没有被覆盖到呢我们是用coverage report -m这个M代表missing啊这里可以看到是第四行没有被覆盖到回到我们的source code发现是return false这行没有覆盖再来看一下我们的test case只测试了这个结果是true的情况没有测试这个结果是false的情况于是我们就增加一个test case除了判断素数3之外我们再判断一下非素数4再跑一下cover就会发现覆盖率100%了当然了有的朋友非常不喜欢CML这个界面对吧他觉得界面实在太粗糙了还有这个没覆盖的行数如果比较多的话一个一个回去对视内行非常麻烦Coverage还提供了HTML的report我们可以使用命令Coverage HTML它会使用同样的数据然后给你建立一个文件夹 html curve我们可以在这个文件夹下跑一个HTB server在浏览器上打开我们开的这个服务器你就可以看到一个更高级版本的report在这里呢我们可以点进去原文件的点击原文件就可以看到我们的原代码如果这个原代码被cover了左边这个部分的都是绿色否则的话就会是红色这样的话哪行代码没有被覆盖就一目了然了那当然有的时候我们测试的不是几个原文件而是一个库举个例子这是我自己的开源像啊 object print那如果我测试是一个安装过的库我们跑一下这个coverage run-munitest在做report的时候你会发现我们could的原代码并没有被报告所有的report都是tests也就是说它实际上在测试我们测试的覆盖率那这是由于cover这个酷在默认的情况下是不会去计算你安装的酷的原代码覆盖率的所以在这里我们可以用-source命令代表你去给我找这个叫 object printed cool并且专门测试这个库的覆盖率我们看这次在report的时候就全部是关于object print的覆盖率了同时我们可以观察到有几个文件的覆盖率非常低这是因为这几个文件是别人的代码我在这个库里面使用到了别人的开源代码那别人在买我是可以不用管它的覆盖率的所以我希望在 [5:00] 覆盖率的时候直接忽略到这些文件那我们在运行这个coverage run的时候呢就可以用这个--omitgoth courage 长成这样的原文件你就不要管了我们看到这次生成的report就只有我自己写的这些文件了那肯定有人说了每次我做carriage run都要打这么长一串太累了尤其是这个ammit命令我根本就记不住这个时候呢就可以用carbjrccoverage rc 相当于是coverage的一个configuration file这里你可以告诉他当我在这个文件夹下使用coverage run的时候你帮我 omit掉下面这个路径有了这个CourageRC文件之后我们再跑一下coverage run 但是不写这个ummit命令我们可以看到report里面也没有刚才的那些文件了那当你需要比较复杂的自定义配置的时候这就是一个很好的方式当然如果我们每次进行完代码修改之后都要在本地跑一下coverage好像也是稍微有些复杂我们可以利用Github actions来帮我们完成这件事我们可以在GitHub Actions上跑这些UnitTest然后产生一个XML report最后使用这个code curve action把这个report给上传到codecub上去CodeCov这个网站就会帮你生成一个非常漂亮的覆盖率的图了你在这个网站上也能看到每一个文件覆盖率的情况当然更重要的是只要你的项目是开源项目这个网站就是免费的我个人现在所有Python的开源项目都在使用这个网站做覆盖率报告最后再聊一个很多人问过我的问题啊就是覆盖率到底多少算够对我个人而言这个数是百分之百因为只有百分之百是质变剩下的都是量变当你觉得95%可以的时候那为什么90%不行呢为什么85%不行呢为什么80%不行呢更重要的是只有在你的覆盖率是100%的时候你才会意识到你新写的代码里有没有被测试到的部分只有从百分之百变到百分之百以下了你才有可能会发现否则的话你代码的总行数变了你这个数肯定会波动你可能意识不到我新写的代码没有被覆盖所以对于个人项目而言我觉得100%是正确的数当然有可能有些情况就是测试不到对于这样的代码我建议大家进行标注也就是在这样的code block上标注上Pragma no cover这是显示的Goth coverage这块不需要去计算覆盖率也就是说所有覆盖不到的代码你都要明确的标记所有能覆盖到的代码全都覆盖当然了如果你只是因为懒就说这块代码覆盖不到那你的覆盖率就是白扯了对吧好那以上就是对单元测试覆盖率以及对Cover这个工具简单介绍如果喜欢的话记得点下关注别忘了一键三零哦字幕志愿者杨茜茜

高天借coverage.py规范Python测试 要求单元测试覆盖率达100%