单元测试、集成测试和端到端测试有什么区别？

简化版

单元测试验证一个小函数或类的逻辑，速度快、依赖少；集成测试验证多个模块或外部组件协作，比如数据库、缓存、HTTP 接口；端到端测试从用户视角验证完整流程。工程上通常遵循测试金字塔：单元测试多，集成测试适量，端到端测试少而关键。

详细版

三类测试的区别：

单元测试：关注最小业务单元，常用 mock 隔离外部依赖；
集成测试：关注模块之间、应用和数据库/缓存/队列之间是否能正确协作；
端到端测试：模拟真实用户或真实调用链，验证完整业务流程。

测试金字塔强调：

底层单元测试数量最多，反馈最快；
中间集成测试覆盖关键组件协作；
顶层 E2E 测试覆盖核心链路，但数量不要过多。

面试中要说明：不是所有问题都靠单元测试解决，也不是所有测试都跑完整链路。不同测试解决不同层次的风险。

完整版教学

一、为什么要分测试层次

软件缺陷可能出现在不同地方。一个函数条件判断写错，是单元级问题；数据库字段映射错误，是集成级问题；用户注册后无法登录，可能是完整链路问题。

如果所有测试都写成端到端测试，确实能贴近真实场景，但会很慢、很脆弱、失败原因难定位。如果所有测试都写成单元测试，又可能发现不了模块协作问题。

所以工程上需要测试层次，让不同测试承担不同职责。

二、单元测试关注什么

单元测试关注最小可测试单元，例如一个函数、一个类、一个 service 方法。它应该运行快、依赖少、失败原因明确。

例如：

def calculate_discount(price, rate):
    if rate < 0 or rate > 1:
        raise ValueError("invalid rate")
    return price * (1 - rate)

def test_calculate_discount():
    assert calculate_discount(100, 0.2) == 80

这个测试不需要数据库、不需要 Web 服务、不需要网络。它验证的是纯业务规则。

单元测试适合覆盖边界条件、异常分支、复杂计算和业务规则。它是最便宜的质量保障。

三、集成测试关注什么

集成测试验证多个组件放在一起是否正常。例如 FastAPI 接口能否正确调用数据库、SQLAlchemy 模型是否映射正确、Redis 缓存是否读写正常、消息队列消费是否符合预期。

示例：

def test_create_user_api(client, db_session):
    resp = client.post("/users", json={"name": "Tom"})
    assert resp.status_code == 201
    assert db_session.query(User).filter_by(name="Tom").first() is not None

这个测试比单元测试慢，但能发现单元测试发现不了的问题，比如路由配置错误、请求模型不匹配、数据库事务失败。

集成测试的关键是控制环境。要使用测试数据库、测试配置、可清理的数据，不能污染生产或开发环境。

四、端到端测试关注什么

端到端测试从用户或外部调用方视角验证完整流程。比如打开浏览器完成注册、登录、下单、支付模拟、查看订单。

在后端 API 项目中，E2E 可能是调用真实部署环境的一串 API：

注册用户 -> 登录获取 token -> 创建订单 -> 支付回调 -> 查询订单状态

E2E 的价值是贴近真实，但代价也最高。它依赖服务部署、网络、数据库、第三方模拟环境，失败时排查成本大。所以 E2E 应覆盖最关键链路，不应该覆盖所有细节。

五、测试金字塔怎么理解

测试金字塔底部是大量单元测试，中间是适量集成测试，顶部是少量 E2E 测试。这个结构的原因是越底层越快、越稳定、越容易定位；越顶层越真实，但越慢、越难维护。

一个健康项目通常是：

大量单元测试：业务规则、纯函数、service 分支
适量集成测试：数据库、API、缓存、消息队列
少量 E2E：核心用户路径、上线前验收

测试金字塔不是死板比例，而是提醒团队不要把所有质量压力都压到昂贵的端到端测试上。

六、如何在 Python 项目落地

Python 项目中，单元测试可以用 pytest 直接写。外部依赖通过 mock 隔离。集成测试可以使用测试数据库、Docker Compose、Testcontainers 或内存替代组件。API 测试可以用 FastAPI TestClient、Django test client 或 httpx。

目录可以按层次拆：

tests/
  unit/
  integration/
  e2e/

CI 中可以每次提交都跑单元测试和关键集成测试，E2E 在合并前、发布前或定时任务中运行。

七、常见误区与追问

测试类型	反馈速度	主要发现的问题
单元测试	毫秒到秒级	业务规则、边界、异常分支
集成测试	秒到分钟级	DB、缓存、API、配置协作
E2E 测试	分钟级以上	用户完整链路和部署环境问题

建议形态：
70% 左右快速单元测试
20% 左右关键集成测试
10% 左右核心 E2E 测试
比例不是硬规则，重点是成本越高数量越克制。

记忆钩子：越底层越快、越稳定、越容易定位；越顶层越真实、越慢、越难排查。

第一个误区是只追求覆盖率数字。覆盖率高不代表测试有效，断言质量和场景选择更重要。

第二个误区是把集成测试写得依赖执行顺序。每个测试都应该能独立运行。

第三个误区是端到端测试太多。E2E 太多会拖慢 CI，还会因为环境抖动造成假失败。

第四个误区是单元测试 mock 过度，导致真正的 SQL、配置、序列化问题完全没被覆盖。

误区：测试层次越真实越好。 全部写成 E2E 会慢、脆弱、失败难定位，应该让不同层次覆盖不同风险。
误区：单元测试能发现所有问题。 单元测试发现不了数据库映射、路由配置、真实序列化、组件协作这类集成问题。
误区：E2E 测试越多质量越高。 E2E 成本高且容易受环境影响，应覆盖最关键用户路径，而不是替代所有低层测试。
追问：测试金字塔是不是固定比例？ 不是固定数学比例，而是工程原则：快速低成本测试多，昂贵真实测试少。
追问：API 项目集成测试通常测什么？ 测路由、请求模型、响应模型、数据库事务、认证依赖、缓存或消息组件协作。
追问：CI 中三类测试怎么安排？ 每次提交跑单元和关键集成，发布前或定时跑较慢 E2E，避免反馈链路太长。

八、加强记忆

记三类测试：单元测试验证小逻辑，集成测试验证组件协作，端到端测试验证完整业务链路。测试金字塔的智慧是把大量快速稳定的测试放底部，把少量真实但昂贵的测试放顶部，让反馈速度和质量保障达到平衡。

简化版

详细版