Python单元测试与集成测试实战：从unittest到pytest的完整工程实践

1. 项目概述：为什么测试是Python开发的“安全带”？

干了这么多年Python开发，我越来越觉得，写测试代码和写业务代码的时间，至少应该五五开。这不是在浪费时间，恰恰相反，这是在为未来的自己“买保险”。想想看，你花三天写了一个功能复杂的模块，上线后运行良好。一个月后，因为一个看似无关的改动，这个模块在凌晨两点突然崩溃，而你早已忘了当初为什么要那么设计。这时候，如果有一份完备的测试套件，它就能像一位永不疲倦的哨兵，在你提交代码的那一刻就发出警报：“嘿，你刚改的这行代码，把三个月前的老功能搞坏了！”

这就是单元测试和集成测试的核心价值。它们不是QA工程师的专属，而是每一位开发者必须掌握的“生存技能”。单元测试，关注的是代码中最小的可测试单元——通常是函数或方法。它的目标是验证这个“零件”在隔离环境下是否按设计工作。而集成测试，则上升一个层级，它关心的是多个“零件”组装在一起后，能否协同工作，数据流是否正确，接口是否匹配。很多人，尤其是刚入行的朋友，容易混淆这两者，或者觉得写测试太麻烦。但我要告诉你，一个没有测试覆盖的项目，就像在悬崖边开车却不系安全带，速度可能很快，但翻车是迟早的事。

Python生态为测试提供了极其友好的环境。unittest是标准库自带的“瑞士军刀”，虽然有些古板，但功能齐全；pytest则是社区宠儿，以其简洁的语法和强大的插件系统，几乎成了事实上的标准。配合coverage.py查看测试覆盖率，用tox管理多环境测试，再通过Jenkins或GitHub Actions集成到CI/CD流水线中，一套现代化的、保障代码质量与稳定性的工程实践就搭建起来了。接下来，我会带你深入这套体系的每一个环节，从最基础的断言怎么写，到如何模拟（Mock）复杂的外部依赖，再到搭建一个高效的持续集成测试流水线。无论你是正在为“vue+单元测试报错”而头疼的前后端开发者，还是想系统学习“python软件工程”的入门者，这篇文章都能给你提供可直接落地的实操方案。

2. 测试策略全景：单元测试与集成测试的分工与协作

在动手写第一行测试代码之前，我们必须先理清思路：什么该用单元测试，什么该用集成测试？两者的边界在哪里？如何配合才能最大化效益？很多团队测试写得痛苦，就是因为策略不清，把集成测试的活儿丢给了单元测试，或者反过来，导致测试脆弱、运行缓慢且难以维护。

2.1 核心概念辨析：单元、集成与端到端测试

让我们用一个网上订餐系统的后端服务来举例。假设有一个OrderService类，它有一个place_order方法。这个方法内部会做几件事：1）验证用户信息和菜品信息（调用UserValidator和MenuValidator）；2）计算总价和折扣（调用PricingCalculator）；3）创建订单记录并保存到数据库（调用OrderRepository）；4）发送订单确认邮件（调用EmailSender）。

• 单元测试：它的关注点是隔离。我们会单独测试UserValidator.validate()函数，给定一个合法的用户ID，它应该返回True；给定一个非法的ID，它应该抛出ValidationError。在这个过程中，UserValidator不能真的去连接数据库查用户是否存在，我们必须“模拟”（Mock）掉数据库查询这个外部依赖。同样，我们会单独测试PricingCalculator.compute()，验证各种优惠券、满减规则是否计算正确。单元测试的特点是快（不涉及I/O）、稳定（结果不依赖外部环境）、精准（失败能立刻定位到具体函数）。
• 集成测试：它的关注点是连接。我们会测试OrderService.place_order()这个方法。但这次，我们不会Mock掉所有东西。一个典型的集成测试场景是：使用一个真实的、但专为测试准备的数据库（如SQLite内存数据库），让OrderRepository真的执行插入操作；同时，Mock掉EmailSender，因为我们不想在测试时真的发邮件。我们验证的是，从接收请求参数，到经过各个组件的处理，最终订单数据被正确持久化到数据库这一整条链路是否通畅。集成测试比单元测试慢，但能发现单元测试发现不了的问题，比如数据库表结构映射错误、事务处理不当、组件间API调用传参错误等。
• 端到端测试：这通常超出了开发者的主要职责，属于QA或自动化测试工程师的范畴。它模拟真实用户操作，从前端点击下单按钮，到请求经过网关、服务层、数据库，再返回响应到前端的完整流程。它运行最慢，也最脆弱，但能验证整个系统是否工作。

对于大多数开发团队，一个健康的测试金字塔应该是：大量的单元测试（底层）、适量的集成测试（中层）、少量的端到端测试（顶层）。我们的精力应该主要投入到单元和集成测试上。

2.2 测试策略制定的核心原则

制定测试策略不是空谈理论，必须结合项目实际。以下是几个关键原则：

1. 根据代码变更频率和重要性确定优先级：对于那些核心业务逻辑、频繁修改的模块（如价格计算引擎），必须要求高覆盖率的单元测试。对于相对稳定、主要是胶水作用的代码（如简单的数据转换层），可以适当降低单元测试要求，用集成测试来覆盖。
2. 隔离不稳定依赖：这是写好单元测试的黄金法则。什么是“不稳定依赖”？网络请求、数据库访问、文件系统操作、系统时间 (datetime.now())、随机数生成器等。这些依赖会导致测试结果不确定、速度慢。在单元测试中，必须使用Mock或Stub来替换它们。
3. 集成测试要测试“集成点”：不要用集成测试去重复验证单元测试已经覆盖的业务逻辑。集成测试的重点应该是各个模块之间的接口（API）、数据流、以及共享资源（如数据库连接池、缓存）的协同工作。例如，测试DAO层与数据库的SQL映射，测试Service层调用第三方API的HTTP客户端配置是否正确。
4. 测试状态 vs 测试行为：这是两种测试风格。测试状态，即调用函数后，验证其返回的结果或对象的状态是否符合预期。测试行为，即验证函数在执行过程中，是否以预期的参数调用了其他依赖函数。后者在测试具有副作用（如发送消息、写入日志）的函数时非常有用。pytest和unittest.mock都提供了强大的工具来支持行为验证。

实操心得：我见过很多项目一开始雄心勃勃，要求100%的测试覆盖率，结果为了覆盖率而写测试，产生了大量 meaningless 的测试（比如单纯getter/setter的测试），反而拖累了开发效率。我的建议是，核心业务逻辑和公共工具库追求高覆盖率（如85%+），而胶水代码和简单的CRUD层可以适当放宽。关键是测试要能真正捕捉到回归缺陷，而不是一个漂亮的覆盖率数字。

3. 单元测试深度实践：从unittest到pytest

掌握了策略，我们进入实战。Python世界有两套主流的单元测试框架，它们各有千秋。

3.1unittest模块：标准库的坚守者

unittest是Python标准库的一部分，它借鉴了JUnit的设计，采用面向对象的方式组织测试。它的优点是无需额外安装，与语言绑定最深，适合对第三方依赖有严格限制的环境。

一个典型的unittest测试用例长这样：

import unittest from mymodule import Calculator class TestCalculator(unittest.TestCase): # 在每个测试方法前运行，用于准备测试数据 def setUp(self): self.calc = Calculator() # 测试用例1：验证加法 def test_add(self): result = self.calc.add(2, 3) self.assertEqual(result, 5) # 断言：结果应等于5 self.assertIsInstance(result, int) # 断言：结果类型应为int # 测试用例2：验证除零错误 def test_divide_by_zero(self): with self.assertRaises(ValueError): # 断言：应抛出ValueError异常 self.calc.divide(10, 0) # 在每个测试方法后运行，用于清理资源 def tearDown(self): del self.calc if __name__ == '__main__': unittest.main()

unittest提供了丰富的断言方法，如assertEqual,assertTrue,assertIn,assertRaises等。它的setUp和tearDown方法可以确保每个测试都在一个干净、独立的环境中运行。对于需要模拟的场景，可以使用标准库中的unittest.mock模块。

unittest.mock实战：隔离你的依赖

假设我们要测试一个发送生日祝福邮件的函数send_birthday_greeting(user_id)，它内部会调用一个UserDatabase类来查询用户生日和邮箱，再调用一个EmailService类来发邮件。在单元测试中，我们绝不能连接真实数据库和邮件服务器。

from unittest.mock import Mock, patch import unittest from myapp import send_birthday_greeting class TestBirthdayGreeting(unittest.TestCase): @patch('myapp.EmailService') # 装饰器：模拟 myapp 模块中的 EmailService 类 @patch('myapp.UserDatabase') def test_send_greeting_to_today_birthday_user(self, MockUserDB, MockEmailService): # 1. 准备模拟数据 mock_user = Mock() mock_user.email = 'test@example.com' mock_user.name = '张三' mock_user.birthday = '1990-05-20' # 2. 配置Mock对象的行为 mock_db_instance = MockUserDB.return_value # 获取模拟的数据库实例 mock_db_instance.get_user_by_id.return_value = mock_user # 让它返回我们准备好的模拟用户 mock_email_instance = MockEmailService.return_value # 获取模拟的邮件服务实例 # 3. 执行被测函数 send_birthday_greeting(user_id=123) # 4. 验证行为（行为测试） # 断言：get_user_by_id 被以正确的参数调用了一次 mock_db_instance.get_user_by_id.assert_called_once_with(123) # 断言：send_email 被调用了一次，并且邮件内容包含了用户的名字 mock_email_instance.send_email.assert_called_once() call_args = mock_email_instance.send_email.call_args self.assertIn('张三', call_args[0][0]) # 检查邮件内容 def test_send_greeting_user_not_found(self): with patch('myapp.UserDatabase') as MockUserDB: mock_db_instance = MockUserDB.return_value mock_db_instance.get_user_by_id.return_value = None # 模拟用户不存在 # 断言：当用户不存在时，函数应静默处理或记录日志，不应崩溃 # 这里我们假设它不会抛出异常 try: send_birthday_greeting(999) # 如果走到这里，说明没抛异常，测试通过 self.assertTrue(True) except Exception: self.fail("函数在用户不存在时抛出了意外异常")

通过Mock和patch，我们完全隔离了外部依赖，使得测试可以快速、稳定地运行，并精确验证函数内部的逻辑和行为。

3.2pytest框架：现代Python测试的标杆

如果说unittest是严谨的教科书，那pytest就是一把锋利的多功能军刀。它几乎不需要样板代码，通过简单的assert语句就能完成所有断言，并且拥有极其丰富的插件生态。

为什么我更推荐pytest？

1. 简洁：不需要继承任何类，测试函数以test_开头即可。
2. 强大的断言：直接使用Python原生的assert，失败时pytest会智能地展示差异，对比assert a == b和unittest的self.assertEqual(a, b)，前者直观太多。
3. Fixture系统：这是pytest的王牌功能。Fixture用于提供测试所需的固定环境，比setUp/tearDown更灵活、更强大，可以跨文件、跨模块共享。
4. 参数化测试：轻松实现用多组数据驱动同一个测试函数。
5. 丰富的插件：如pytest-cov（覆盖率）、pytest-mock（集成mock）、pytest-xdist（并行测试）、pytest-asyncio（异步测试）等。

pytest基础与 Fixture 魔法

# test_calculator.py import pytest from mymodule import Calculator # 定义一个Fixture，作用域是“函数”（默认），即每个测试函数都会重新执行一次 @pytest.fixture def calculator(): print("\n创建新的Calculator实例") return Calculator() # 如果需要清理，可以使用 yield # calc = Calculator() # yield calc # print("\n清理Calculator实例") # calc.cleanup() # 测试函数，通过参数名自动注入同名的Fixture def test_add(calculator): result = calculator.add(2, 3) assert result == 5 def test_subtract(calculator): assert calculator.subtract(5, 3) == 2 # 参数化测试：用多组输入输出测试同一个逻辑 @pytest.mark.parametrize("a, b, expected", [ (1, 2, 3), (5, -5, 0), (100, 200, 300), ]) def test_add_parametrized(calculator, a, b, expected): assert calculator.add(a, b) == expected # 使用内置的 tmp_path Fixture 来操作临时文件系统 def test_create_file(tmp_path): d = tmp_path / "sub" d.mkdir() p = d / "hello.txt" p.write_text("Hello, pytest!") assert p.read_text() == "Hello, pytest!"

pytest-mock插件：更优雅的模拟

pytest通过pytest-mock插件提供了mockerFixture，让Mock操作更集成化。

import pytest from myapp import send_birthday_greeting def test_send_greeting(mocker): # 注入 mocker Fixture # 模拟依赖 mock_user_db = mocker.patch('myapp.UserDatabase') mock_email_service = mocker.patch('myapp.EmailService') # 配置模拟对象 mock_user = mocker.Mock(email='test@example.com', name='李四') mock_user_db.return_value.get_user_by_id.return_value = mock_user # 执行 send_birthday_greeting(456) # 断言 mock_user_db.return_value.get_user_by_id.assert_called_once_with(456) mock_email_service.return_value.send_email.assert_called_once() # 可以更细致地检查调用参数 call_args = mock_email_service.return_value.send_email.call_args assert '李四' in call_args[0][0] assert 'test@example.com' in call_args[0][1]

避坑技巧：使用mocker.patch时，补丁路径必须指向被测对象（这里是myapp）看到的目标对象。如果你的测试文件在tests/目录下，而代码在src/下，你需要确保导入路径正确。一个常见错误是在测试文件中from src.myapp import ...，然后在测试中patchsrc.myapp.XXX，但实际运行时代码可能从别的地方导入。使用sys.modules中的完整路径是最稳妥的。

4. 集成测试实战：连接真实组件，验证协作流程

单元测试保证了每个齿轮是完好的，集成测试则要验证这些齿轮组装成钟表后能否准确报时。在Python中，集成测试通常意味着要和一个或多个外部系统打交道，比如数据库、缓存、消息队列、HTTP API等。

4.1 测试数据库交互：使用测试专用数据库

对于涉及数据库的代码，集成测试的目标是验证ORM映射、SQL语句、事务管理是否正确。绝对不要使用生产数据库！通常有以下几种策略：

1. SQLite内存数据库：对于Django ORM、SQLAlchemy等支持多后端的ORM，这是最快、最干净的选择。每个测试用例都在一个全新的、运行在内存中的数据库上操作，测试结束后自动销毁，无残留。
2. Docker容器启动临时数据库：如果必须使用MySQL、PostgreSQL等特定数据库，可以使用docker-compose或pytest-docker插件在测试开始时启动一个干净的数据库容器，测试结束后停止并移除。这能保证环境的一致性。
3. 使用事务回滚：在测试类的setUp中开启一个事务，在tearDown中回滚。这样测试中对数据库的修改不会真正提交。但这种方法对DDL（创建表）操作无效，且需要数据库驱动支持。

以SQLAlchemy + pytest为例：

# conftest.py (pytest会自动发现这个文件中的Fixture) import pytest from sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker, scoped_session from myapp.models import Base, User @pytest.fixture(scope='session') # 会话级Fixture，所有测试只执行一次 def engine(): # 创建连接到内存SQLite的引擎 return create_engine('sqlite:///:memory:', echo=False) @pytest.fixture(scope='session') def tables(engine): # 创建所有表结构 Base.metadata.create_all(engine) yield # 测试会话结束后，可以删除表（对于内存数据库，断开连接即销毁） Base.metadata.drop_all(engine) @pytest.fixture def db_session(engine, tables): # 为每个测试函数创建一个新的、独立的事务和会话 connection = engine.connect() transaction = connection.begin() Session = scoped_session(sessionmaker(bind=connection)) yield Session # 测试结束后，回滚事务并关闭会话 Session.remove() transaction.rollback() connection.close() # test_user_repository.py def test_create_and_get_user(db_session): from myapp.repositories import UserRepository repo = UserRepository(db_session) # 创建用户 new_user = repo.create_user(name='王五', email='wangwu@example.com') assert new_user.id is not None # 查询用户 fetched_user = repo.get_user_by_id(new_user.id) assert fetched_user is not None assert fetched_user.name == '王五' assert fetched_user.email == 'wangwu@example.com' # 验证数据库约束，如唯一邮箱 import sqlalchemy.exc with pytest.raises(sqlalchemy.exc.IntegrityError): repo.create_user(name='赵六', email='wangwu@example.com') # 重复邮箱应报错

这个Fixture设计确保了每个测试函数都在一个干净的数据库环境中运行，即使测试失败，数据也不会污染后续测试。

4.2 测试HTTP API：使用responses或httpx模拟外部服务

现代应用离不开HTTP API调用。集成测试需要验证我们的代码能正确处理各种HTTP响应（200成功、404未找到、500服务器错误等）。我们不应该在测试中真的去调用外部服务（慢、不稳定、可能有副作用），而是应该拦截这些请求。

使用responses库（适用于requests库）：

import pytest import responses from myapp.external_service import fetch_weather_data @responses.activate # 激活响应模拟 def test_fetch_weather_success(): # 模拟一个成功的API响应 mock_response_json = {'city': 'Beijing', 'temp': 22, 'condition': 'Sunny'} responses.add( responses.GET, 'https://api.weather.com/v1/current', json=mock_response_json, status=200 ) result = fetch_weather_data('Beijing') assert result['city'] == 'Beijing' assert result['temperature'] == 22 # 验证我们的函数确实发起了请求 assert len(responses.calls) == 1 assert responses.calls[0].request.url == 'https://api.weather.com/v1/current?city=Beijing' @responses.activate def test_fetch_weather_not_found(): # 模拟一个404响应 responses.add( responses.GET, 'https://api.weather.com/v1/current', json={'error': 'City not found'}, status=404 ) result = fetch_weather_data('UnknownCity') assert result is None # 我们的函数应该处理404，返回None或抛出特定异常 @responses.activate def test_fetch_weather_timeout(): # 模拟请求超时 responses.add( responses.GET, 'https://api.weather.com/v1/current', body=requests.exceptions.Timeout() ) with pytest.raises(requests.exceptions.Timeout): fetch_weather_data('Beijing')

对于异步HTTP客户端（如httpx,aiohttp），可以使用pytest-asyncio配合respx或aioresponses库进行类似模拟。

4.3 集成测试的组织与运行

集成测试通常比单元测试慢，因此好的组织方式很重要：

• 标记测试：使用pytest的标记功能，将集成测试与单元测试分开。

  import pytest @pytest.mark.integration # 自定义一个标记 def test_database_integration(): ...

  然后可以通过命令行只运行单元测试或集成测试：

  pytest -m "not integration" # 只运行单元测试 pytest -m integration # 只运行集成测试

• 使用CI/CD分阶段运行：在Jenkins或GitHub Actions的流水线中，先快速运行单元测试，只有通过后才运行更耗时的集成测试，提高反馈效率。

5. 搭建持续集成测试流水线：让测试自动化运转

写好的测试如果只在自己电脑上运行，价值就大打折扣。持续集成（CI）的核心是：每次代码变更（Push或Merge Request）都自动触发完整的测试套件运行。这能尽早发现集成错误，保证主分支的代码始终处于可部署状态。

5.1 使用GitHub Actions进行CI测试

GitHub Actions因其与GitHub的无缝集成和强大的免费额度，成为开源和私有项目的首选。下面是一个典型的Python项目CI工作流配置：

# .github/workflows/test.yml name: Python CI on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest strategy: matrix: python-version: ['3.9', '3.10', '3.11'] # 多版本Python测试 steps: - uses: actions/checkout@v4 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v5 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-dev.txt # 开发依赖，如pytest, coverage等 - name: Lint with flake8 (代码风格检查) run: | flake8 . --count --max-complexity=10 --statistics - name: Run unit tests with pytest run: | pytest tests/unit/ -v --cov=src --cov-report=xml --cov-report=term-missing - name: Upload coverage to Codecov (可选，用于可视化覆盖率报告) uses: codecov/codecov-action@v3 with: file: ./coverage.xml # 集成测试可能需要额外的服务，如数据库 - name: Start PostgreSQL for integration tests run: | sudo systemctl start postgresql sudo -u postgres psql -c "CREATE DATABASE test_db;" # 或者使用Docker: docker run -d -p 5432:5432 postgres:13 - name: Run integration tests env: DATABASE_URL: postgresql://postgres:@localhost/test_db run: | pytest tests/integration/ -v --tb=short

这个工作流做了几件事：1）在多个Python版本下运行测试；2）先进行代码风格检查；3）运行单元测试并生成覆盖率报告；4）启动一个测试数据库；5）运行集成测试。任何一步失败，整个工作流就会标记为失败，阻止有问题的代码合并。

5.2 使用Tox管理多环境测试矩阵

如果你的项目需要支持更多样的环境（如不同Python版本+不同依赖版本组合），tox是一个强大的工具。它可以在本地或CI中自动创建虚拟环境，安装指定依赖，并运行测试。

tox.ini配置文件示例：

[tox] envlist = py39, py310, py311, lint, docs isolated_build = true [testenv] deps = pytest pytest-cov responses commands = pytest tests/ -v --cov=src --cov-report=xml [testenv:lint] deps = flake8 black isort commands = flake8 src tests black --check src tests isort --check-only src tests [testenv:docs] deps = sphinx commands = sphinx-build -b html docs/source docs/build/html

在CI中，你可以简单地运行tox，它会自动处理所有环境的测试。

实操心得：在CI中，一定要让测试失败变得显眼。可以将CI状态徽章放在README最前面，并配置Slack或钉钉等通知，在测试失败时及时提醒团队。同时，要关注测试的运行时间。如果集成测试套件需要运行30分钟，开发体验会非常糟糕。考虑将集成测试分层，核心链路的关键集成测试在每次提交时运行，而全量的、端到端的集成测试可以每天在夜间定时运行。

6. 高级技巧与常见问题排查

即使掌握了基本方法，在实际项目中还是会遇到各种棘手问题。这里分享一些高级技巧和常见坑的解决方案。

6.1 测试“不可测”的代码：时间、随机数与单例

有些代码因为依赖全局状态或非确定性因素而难以测试。

• 依赖当前时间：不要直接在代码中使用datetime.now()或time.time()。应该将其作为参数传入，或者使用依赖注入。

  # 难测试的代码 def is_morning(): return datetime.now().hour < 12 # 可测试的代码 def is_morning(now: datetime): return now.hour < 12 # 或者使用第三方库如`freezegun`在测试中冻结时间 from freezegun import freeze_time @freeze_time("2023-10-27 09:00:00") def test_is_morning(): assert is_morning() == True

• 随机数：同理，将随机数生成器作为参数注入。

  def generate_token(random_generator=None): if random_generator is None: random_generator = random.SystemRandom() return ''.join(random_generator.choice(string.ascii_letters) for _ in range(32)) # 测试中 def test_generate_token(): fixed_random = mock.Mock(spec=random.Random) fixed_random.choice.side_effect = ['a', 'b', 'c', 'd'] # 模拟固定的随机序列 token = generate_token(fixed_random) assert token == 'abcd' assert fixed_random.choice.call_count == 4

• 单例和全局状态：这是测试的“天敌”。尽量使用依赖注入，避免在模块层面初始化全局客户端（如数据库连接、Redis客户端、配置对象）。如果无法避免，可以使用unittest.mock.patch在测试时替换掉这个全局对象。

6.2 测试异步代码

对于使用asyncio的异步代码，pytest-asyncio插件是必备的。

import pytest import asyncio from myapp.async_service import fetch_concurrently @pytest.mark.asyncio async def test_fetch_concurrently(): # 模拟一个异步函数 async def mock_fetch(url): await asyncio.sleep(0.01) return f"data_from_{url}" urls = ['url1', 'url2', 'url3'] # 测试异步函数 results = await fetch_concurrently(urls, mock_fetch) assert len(results) == 3 assert 'data_from_url1' in results

6.3 常见问题排查速查表

6.4 测试代码的维护：保持测试的清洁与高效

测试代码也是代码，也需要维护。坏掉的测试（False Negative）和从不失败的测试（False Positive）同样有害。

• 遵循DRY原则，但适度：使用Fixture、工厂函数来消除重复的测试数据准备代码。但也要避免过度抽象，让测试逻辑变得晦涩难懂。
• 测试名称要具有描述性：test_user_login_success比test_login_1好得多。好的测试名应该能说明在什么条件下，执行什么操作，期望什么结果。
• 一个测试断言一件事：如果一个测试函数里塞了十几个assert，一旦失败，很难快速定位根本原因。尽量让测试函数聚焦于一个特定的场景或行为。
• 定期审查和清理测试：删除那些测试已不存在功能的用例，合并重复的测试，重构臃肿的测试。将慢速的集成测试移出核心开发循环。

写测试是一种投资。初期看似花费了更多时间，但它带来的代码信心、快速重构能力和清晰的文档价值，会在项目的整个生命周期中带来数十倍的回报。从今天开始，为你写的每一个新功能，都配上相应的测试吧。当你某次修改代码后，测试套件“啪”地一下亮起红灯，精准地指出你引入的回归错误时，你会感谢当初写测试的那个自己。