unittest和pytest是Python中主流的测试框架，前者是标准库、需继承TestCase类，后者更灵活、支持原生assert；推荐根据项目需求选择，pytest适合大多数场景，而unittest适用于无外部依赖限制的项目。
unittest
和
pytest
都是Python生态中用于编写和运行单元测试的核心工具。简单来说，
unittest
是Python标准库自带的测试框架，历史悠久，遵循xUnit风格；而
pytest
则是一个更现代、功能更强大、语法更简洁的第三方框架，以其丰富的插件和灵活的测试发现机制受到广泛欢迎。选择哪个，很大程度上取决于你对测试风格的偏好、项目的具体需求，以及团队成员的熟悉程度。
解决方案
要使用
unittest
或
pytest
进行单元测试，我们通常会针对代码中的独立功能单元（比如一个函数、一个方法）编写测试用例。这不仅仅是为了验证功能是否按预期工作，更是为了在代码重构或功能迭代时，提供一道可靠的防线。
使用
unittest
unittest
的使用方式相对规范，它要求你创建继承自
unittest.TestCase
的测试类。每个测试方法都必须以
test_
开头。
假设我们有一个简单的计算器模块
calculator.py
：
# calculator.pydef add(a, b): return a + bdef subtract(a, b): return a - bdef multiply(a, b): return a * bdef divide(a, b): if b == 0: raise ValueError("Cannot divide by zero!") return a / b
这是我们用
unittest
编写的测试：
# test_calculator_unittest.pyimport unittestfrom calculator import add, subtract, multiply, divideclass TestCalculator(unittest.TestCase): def setUp(self): """每个测试方法运行前都会执行，可以用于初始化资源""" self.a = 10 self.b = 5 # print("nsetUp called") # 调试用 def tearDown(self): """每个测试方法运行后都会执行，用于清理资源""" # print("tearDown called") # 调试用 pass def test_add(self): """测试加法功能""" result = add(self.a, self.b) self.assertEqual(result, 15) self.assertEqual(add(-1, 1), 0) self.assertEqual(add(-1, -1), -2) def test_subtract(self): """测试减法功能""" result = subtract(self.a, self.b) self.assertEqual(result, 5) self.assertEqual(subtract(5, 10), -5) def test_multiply(self): """测试乘法功能""" result = multiply(self.a, self.b) self.assertEqual(result, 50) self.assertEqual(multiply(-2, 3), -6) def test_divide(self): """测试除法功能""" result = divide(self.a, self.b) self.assertEqual(result, 2.0) self.assertAlmostEqual(divide(10, 3), 3.333333, places=6) def test_divide_by_zero_raises_error(self): """测试除数为零时是否抛出ValueError""" with self.assertRaises(ValueError): divide(10, 0)# 如果直接运行此文件，可以这样发现并运行测试if __name__ == '__main__': unittest.main()
运行方式：
在项目根目录运行
python -m unittest discover
或者直接运行
python test_calculator_unittest.py
使用
pytest
pytest
则更加灵活，它不需要你继承任何类，只需要编写以
test_
开头的文件（或目录），并在文件中编写以
test_
开头的函数即可。它的断言直接使用Python内置的
assert
语句，非常直观。
# test_calculator_pytest.pyimport pytestfrom calculator import add, subtract, multiply, divide# 我们可以使用fixture来设置共享资源，比unittest的setUp/tearDown更灵活@pytest.fixturedef setup_numbers(): """提供一些用于测试的数字""" return 10, 5def test_add(setup_numbers): a, b = setup_numbers assert add(a, b) == 15 assert add(-1, 1) == 0 assert add(-1, -1) == -2def test_subtract(setup_numbers): a, b = setup_numbers assert subtract(a, b) == 5 assert subtract(5, 10) == -5def test_multiply(setup_numbers): a, b = setup_numbers assert multiply(a, b) == 50 assert multiply(-2, 3) == -6def test_divide(setup_numbers): a, b = setup_numbers assert divide(a, b) == 2.0 # pytest也支持浮点数近似比较 assert divide(10, 3) == pytest.approx(3.333333)def test_divide_by_zero_raises_error(): with pytest.raises(ValueError, match="Cannot divide by zero!"): divide(10, 0)
运行方式：
确保你已经安装了
pytest
(
pip install pytest
)在项目根目录运行
pytest
我个人更倾向于
pytest
，因为它写起来更像普通的Python代码，学习曲线更平缓，而且它的fixture机制在处理复杂测试设置时，比
unittest
的
setUp
/
tearDown
更加强大和模块化。不过，
unittest
作为标准库的一部分，不需要额外安装，在一些简单或对外部依赖有严格限制的项目中，依然是很好的选择。
单元测试与集成测试，如何选择与平衡？
在软件开发中，单元测试（Unit Test）和集成测试（Integration Test）是两种非常重要的测试类型，它们关注的粒度和目的截然不同。理解它们的区别并合理分配测试资源，对于构建健壮的系统至关重要。
单元测试，顾名思义，是针对代码中最小的可测试单元（如一个函数、一个方法、一个类）进行的测试。它的核心思想是隔离，即测试时尽量排除外部依赖，确保被测试单元在独立环境下行为正确。这意味着我们会使用 Mock 或 Stub 来模拟数据库连接、网络请求、外部API调用等，以确保测试的焦点仅限于该单元自身的逻辑。我常把单元测试比作检查生产线上的每一个螺丝钉是否合格，它应该快速、独立，并且能精确指出问题所在。
集成测试则不然，它关注的是多个单元或组件之间的协作是否正确。当我们将不同的模块、服务或系统整合在一起时，集成测试就派上用场了。它会验证这些组件在真实或接近真实的环境下，能否协同工作，数据流转是否顺畅，接口调用是否符合预期。比如，一个用户注册功能，单元测试可能只检查密码加密函数是否正确，而集成测试会模拟用户注册的整个流程，包括前端提交数据、后端验证、数据库写入、邮件发送等。这就像是检查生产线上不同工位的机器能否顺利衔接，最终产出完整的产品。
如何选择和平衡？这其实是个资源分配的问题。我的经验是，大部分测试资源应该投入到单元测试中。因为单元测试能够提供最快的反馈，定位问题最精确，而且运行成本最低。当一个单元测试失败时，我们能立即知道是哪个函数或方法出了问题。应该尽可能地提高核心业务逻辑的单元测试覆盖率。
然而，单元测试的局限性在于，它无法保证不同组件集成后的正确性。所以，集成测试是不可或缺的补充。我们不应该为每个可能的集成路径都编写详尽的集成测试，那会非常耗时且难以维护。相反，应该聚焦于关键业务流程、核心数据流以及那些容易出错的集成点。例如，所有与外部服务交互的接口、数据库操作的读写路径，都应该有对应的集成测试来保障。
一个实用的策略是采用“测试金字塔”模型：大量的单元测试在底层，中等数量的集成测试在中间层，少量端到端测试（E2E Test）在顶层。这能确保我们在开发初期就能快速发现并修复大部分问题，同时也能对系统整体的健康状况有一个全面的把握。平衡的关键在于：单元测试要“深而广”，覆盖所有内部逻辑；集成测试要“准而精”，覆盖关键交互路径。
编写高效且可维护的单元测试有哪些最佳实践？
编写单元测试，不仅仅是为了测试功能，更是为了提高代码质量、加速开发进程。但如果测试本身写得一团糟，那它就会成为维护的负担。在我看来，以下几点是编写高效且可维护单元测试的关键：
首先，测试应该独立且可重复。每个测试用例都应该能够独立运行，不依赖于其他测试用例的执行顺序或状态。这意味着测试环境的设置和清理至关重要，
unittest
的
setUp
/
tearDown
或
pytest
的fixture就是为此而生。如果一个测试的失败会导致其他测试失败，或者只有在特定顺序下才能通过，那么这个测试就是有问题的。
其次，测试应该只关注一个方面。一个测试用例应该只测试被测单元的一个特定行为或一个特定输入输出组合。避免在一个测试中验证多个不相关的逻辑。这有助于在测试失败时，快速定位到具体的问题。给测试函数起一个描述性的名字，例如
test_add_two_positive_numbers_returns_correct_sum
，而不是简单的
test_add
，能大大提高可读性。
再者，测试应该快速运行。单元测试的价值在于其快速反馈能力。如果你的单元测试需要几秒甚至几十秒才能跑完，那么开发者就不太可能频繁地运行它们，从而失去了早期发现问题的优势。避免在单元测试中进行真实的I/O操作（如数据库访问、网络请求），使用Mock对象来模拟这些耗时或不可控的外部依赖。
还有，使用明确的断言。选择最能表达意图的断言方法。例如，
self.assertEqual(a, b)
比
assert a == b
在
unittest
中更具表现力，而
pytest
则直接使用原生的
assert
，配合其强大的断言重写机制，能给出非常详细的失败信息。对于浮点数比较，一定要使用近似比较（如
self.assertAlmostEqual
或
pytest.approx
），避免因浮点数精度问题导致的假性失败。
最后，保持测试代码的整洁和可读性。测试代码也是代码，它也需要遵循良好的编码规范。避免复制粘贴大量的测试逻辑，可以考虑使用参数化测试（
pytest
的
@pytest.mark.parametrize
功能非常强大）来减少重复代码。当我看到一个测试文件比被测试的生产代码还要复杂时，我就会开始反思，这个测试是不是写得太重了，或者被测试的代码是不是设计得过于复杂了。一个好的测试，本身就应该像一份清晰的功能说明书。
如何在CI/CD流程中自动化运行单元测试？
将单元测试自动化集成到CI/CD（持续集成/持续部署）流程中，是现代软件开发不可或缺的一环。这不仅仅是为了提高开发效率，更是为了确保每次代码变更都能得到即时验证，从而大幅降低引入bug的风险，并提升软件发布的信心。
我通常会将测试阶段作为CI/CD管道中的一个早期步骤。当开发者提交代码到版本控制系统（如Git）后，CI服务器（如Jenkins, GitLab CI, GitHub Actions, CircleCI等）会自动触发构建流程。
典型的自动化运行单元测试步骤包括：
环境准备：CI/CD管道首先需要一个干净的环境来运行测试。这通常涉及拉取最新的代码，并安装项目所需的所有依赖。例如，对于Python项目，通常会运行
pip install -r requirements.txt
。确保测试环境与开发环境尽可能一致，可以避免“在我机器上能跑”的问题。
执行测试：这是核心步骤。根据你选择的测试框架，执行相应的命令来运行单元测试。
对于
unittest
：
python -m unittest discover
。这个命令会自动在当前目录及其子目录中查找所有以
test_
开头的文件，并运行其中的测试。对于
pytest
：
pytest
。
pytest
默认会自动发现以
test_
开头的文件和函数。
生成测试报告：为了让CI/CD系统能够解析测试结果，并提供可视化的报告，通常会要求测试框架生成特定格式的报告。最常用的是JUnit XML格式。
对于
unittest
：可以结合
xmlrunner
等第三方库生成，例如
python -m xmlrunner discover
。对于
pytest
：非常简单，只需添加参数
pytest --junitxml=report.xml
即可。
代码覆盖率报告：除了测试通过与否，代码覆盖率也是衡量测试质量的重要指标。
对于
unittest
或
pytest
：通常会结合
coverage.py
工具。例如，运行
coverage run -m pytest
或
coverage run -m unittest discover
，然后生成报告
coverage report
或
coverage xml -o coverage.xml
。这些报告可以帮助我们识别哪些代码路径还没有被测试覆盖到。
结果分析与反馈：CI/CD系统会解析生成的测试报告（如
report.xml
），并根据测试结果来决定管道的下一步动作。如果所有测试都通过，管道可以继续进行后续的构建、打包、部署等步骤。但如果任何一个单元测试失败，或者代码覆盖率低于预设的阈值，CI/CD管道应该立即中断，并将失败信息反馈给开发者（通过邮件、Slack通知等），这样开发者就能及时修复问题。
自动化测试的价值在于，它将测试的责任从人工转移到了机器，确保了每次变更都经过了同样的、严格的质量检查。它为快速迭代和频繁发布提供了坚实的基础，让我能够更放心地交付代码。
以上就是如何使用 unittest 或 pytest 进行单元测试？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1369691.html
微信扫一扫 
支付宝扫一扫 
