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和MenuValidator2计算总价和折扣调用PricingCalculator3创建订单记录并保存到数据库调用OrderRepository4发送订单确认邮件调用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 测试策略制定的核心原则制定测试策略不是空谈理论必须结合项目实际。以下是几个关键原则根据代码变更频率和重要性确定优先级对于那些核心业务逻辑、频繁修改的模块如价格计算引擎必须要求高覆盖率的单元测试。对于相对稳定、主要是胶水作用的代码如简单的数据转换层可以适当降低单元测试要求用集成测试来覆盖。隔离不稳定依赖这是写好单元测试的黄金法则。什么是“不稳定依赖”网络请求、数据库访问、文件系统操作、系统时间 (datetime.now())、随机数生成器等。这些依赖会导致测试结果不确定、速度慢。在单元测试中必须使用Mock或Stub来替换它们。集成测试要测试“集成点”不要用集成测试去重复验证单元测试已经覆盖的业务逻辑。集成测试的重点应该是各个模块之间的接口API、数据流、以及共享资源如数据库连接池、缓存的协同工作。例如测试DAO层与数据库的SQL映射测试Service层调用第三方API的HTTP客户端配置是否正确。测试状态 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 testexample.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_id123) # 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简洁不需要继承任何类测试函数以test_开头即可。强大的断言直接使用Python原生的assert失败时pytest会智能地展示差异对比assert a b和unittest的self.assertEqual(a, b)前者直观太多。Fixture系统这是pytest的王牌功能。Fixture用于提供测试所需的固定环境比setUp/tearDown更灵活、更强大可以跨文件、跨模块共享。参数化测试轻松实现用多组数据驱动同一个测试函数。丰富的插件如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(emailtestexample.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 testexample.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语句、事务管理是否正确。绝对不要使用生产数据库通常有以下几种策略SQLite内存数据库对于Django ORM、SQLAlchemy等支持多后端的ORM这是最快、最干净的选择。每个测试用例都在一个全新的、运行在内存中的数据库上操作测试结束后自动销毁无残留。Docker容器启动临时数据库如果必须使用MySQL、PostgreSQL等特定数据库可以使用docker-compose或pytest-docker插件在测试开始时启动一个干净的数据库容器测试结束后停止并移除。这能保证环境的一致性。使用事务回滚在测试类的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(scopesession) # 会话级Fixture所有测试只执行一次 def engine(): # 创建连接到内存SQLite的引擎 return create_engine(sqlite:///:memory:, echoFalse) pytest.fixture(scopesession) 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(bindconnection)) 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王五, emailwangwuexample.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 wangwuexample.com # 验证数据库约束如唯一邮箱 import sqlalchemy.exc with pytest.raises(sqlalchemy.exc.IntegrityError): repo.create_user(name赵六, emailwangwuexample.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, jsonmock_response_json, status200 ) 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?cityBeijing responses.activate def test_fetch_weather_not_found(): # 模拟一个404响应 responses.add( responses.GET, https://api.weather.com/v1/current, json{error: City not found}, status404 ) 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, bodyrequests.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/checkoutv4 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-pythonv5 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-complexity10 --statistics - name: Run unit tests with pytest run: | pytest tests/unit/ -v --covsrc --cov-reportxml --cov-reportterm-missing - name: Upload coverage to Codecov (可选用于可视化覆盖率报告) uses: codecov/codecov-actionv3 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 --tbshort这个工作流做了几件事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 --covsrc --cov-reportxml [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_generatorNone): 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(specrandom.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 fdata_from_{url} urls [url1, url2, url3] # 测试异步函数 results await fetch_concurrently(urls, mock_fetch) assert len(results) 3 assert data_from_url1 in results6.3 常见问题排查速查表问题现象可能原因解决方案ImportError或ModuleNotFoundError测试运行路径与项目结构不匹配导致Python找不到模块。1. 确保在项目根目录运行pytest。2. 使用python -m pytest代替pytest命令。3. 在pyproject.toml或setup.cfg中配置pythonpath。4. 使用sys.path.insert或设置PYTHONPATH环境变量。Mock不生效Patch的路径不对。Mock了A模块中的类但被测代码从B模块导入。1. 使用print(sys.modules)查看实际导入的模块路径。2.Patch对象在被测代码的命名空间中的位置而不是在测试文件中的位置。遵循“见什么补什么”原则。数据库测试数据污染测试没有正确隔离一个测试创建的数据影响了另一个测试。1. 使用事务回滚db.session.begin_nested()。2. 使用setUp/tearDown或pytest.fixture为每个测试创建全新的数据库如SQLite内存库。3. 使用随机或唯一的测试数据如UUID。集成测试速度慢1. 测试启动/关闭外部服务耗时。2. 单个测试执行大量I/O。1. 使用会话级(scopesession)Fixture来共享昂贵的资源如数据库连接。2. 将测试并行化pytest-xdist。3. 优化测试用例减少不必要的重复操作。测试时好时坏Flaky Tests测试依赖时序、并发、未清理的外部状态或随机性。1. 消除竞态条件使用锁或更确定性的等待。2. 彻底Mock所有外部依赖。3. 使用pytest-flakefinder插件多次运行疑似不稳定的测试来确认。覆盖率报告不准1. 测试运行器没有正确测量。2. 动态生成的代码未被覆盖。1. 确保使用pytest-cov并正确配置--cov参数指向源码目录。2. 检查.coveragerc文件排除无需覆盖的文件如迁移文件、模板。6.4 测试代码的维护保持测试的清洁与高效测试代码也是代码也需要维护。坏掉的测试False Negative和从不失败的测试False Positive同样有害。遵循DRY原则但适度使用Fixture、工厂函数来消除重复的测试数据准备代码。但也要避免过度抽象让测试逻辑变得晦涩难懂。测试名称要具有描述性test_user_login_success比test_login_1好得多。好的测试名应该能说明在什么条件下执行什么操作期望什么结果。一个测试断言一件事如果一个测试函数里塞了十几个assert一旦失败很难快速定位根本原因。尽量让测试函数聚焦于一个特定的场景或行为。定期审查和清理测试删除那些测试已不存在功能的用例合并重复的测试重构臃肿的测试。将慢速的集成测试移出核心开发循环。写测试是一种投资。初期看似花费了更多时间但它带来的代码信心、快速重构能力和清晰的文档价值会在项目的整个生命周期中带来数十倍的回报。从今天开始为你写的每一个新功能都配上相应的测试吧。当你某次修改代码后测试套件“啪”地一下亮起红灯精准地指出你引入的回归错误时你会感谢当初写测试的那个自己。