3、依赖隔离概念：为什么在数据库测试中需要隔离外部依赖
在 PostgreSQL 数据库测试中，依赖隔离是指将待测试的数据库逻辑与外部系统（如第三方 API、其他数据库、消息队列、文件系统等）完全解耦，确保测试仅针对数据库本身的行为进行验证。缺乏依赖隔离的测试会引入不确定性、执行缓慢、难以重现等问题，严重削弱测试的有效性。
3.1 外部依赖带来的测试风险
当数据库测试直接依赖外部系统时，会面临以下典型风险：
| 风险类别 | 具体表现 | 对测试的影响 |
|---|---|---|
| 网络不稳定 | 第三方 API 超时、DNS 解析失败、连接池耗尽 | 测试结果不可预测，偶发失败（Flaky Test） |
| 数据状态不可控 | 外部数据库中的数据被其他进程修改 | 测试无法复现相同初始条件，断言失效 |
| 速率限制 | 第三方 API 对请求频率有限制 | 批量测试时被限流，测试执行中断 |
| 认证与权限 | 外部系统需要动态 Token、证书或 IP 白名单 | 测试环境配置复杂，CI/CD 流水线难以集成 |
| 版本兼容性 | 外部 API 升级导致返回格式变化 | 数据库测试因外部变更而失败，定位困难 |
常见误区： 很多团队认为"只要在测试前手动准备好外部数据"就能解决问题。实际上，手动准备的数据无法保证每次测试的隔离性，且无法在并行测试中避免数据污染。
3.2 依赖隔离的核心原则
在 PostgreSQL 测试中实施依赖隔离，需要遵循以下原则：
- 测试边界内聚：每个测试用例只验证数据库内部逻辑（存储过程、函数、触发器、权限检查），不验证外部系统的行为。
- 外部依赖 Mock 化：使用模拟对象（Mock）或桩（Stub）替代真实的外部调用，返回预定义的响应数据。
- 数据自包含：测试所需的全部数据由测试用例自身创建，测试结束后自动清理，不依赖外部数据源。
- 幂等执行：同一测试用例可重复执行任意次数，每次结果一致，不受外部状态影响。
3.3 依赖隔离的架构对比
下图展示了未隔离与隔离后的测试架构差异：
3.4 依赖隔离的典型实现策略
在 PostgreSQL 测试中，常用的依赖隔离策略包括：
| 策略 | 适用场景 | 实现方式 | 隔离级别 |
|---|---|---|---|
| 数据库内 Mock 函数 | 存储过程调用外部 API | 创建同名的 Mock 函数替换真实函数，返回固定 JSON | 高 |
| 临时 Schema/表 | 依赖其他数据库表 | 在测试 Schema 中创建临时表，测试结束 DROP | 高 |
| 事务回滚 | 修改外部数据后需要还原 | 在事务中执行测试，最后 ROLLBACK | 中 |
| 环境变量注入 | 动态切换外部端点 | 通过 current_setting() 读取自定义参数 |
中 |
| FDW 模拟 | 外部数据包装器（Foreign Data Wrapper） | 创建本地 Mock 外部表，不连接真实远程库 | 高 |
最佳实践： 在 PostgreSQL 中，优先使用数据库内 Mock 函数策略。例如，如果生产环境有一个调用第三方支付 API 的函数
payment_charge()，测试时创建一个同名的 Mock 函数，返回预定义的支付结果 JSON，测试代码无需任何修改即可获得隔离效果。
3.5 依赖隔离的收益量化
实施依赖隔离后，测试质量指标通常会有显著改善：
- 测试执行时间：从依赖外部 API 的 3-15 秒/用例，降低到 Mock 后的 50-200 毫秒/用例，提速约 30-60 倍。
- 测试稳定性：Flaky Test 比例从 15%-30% 降低到 1% 以下。
- 并行执行能力：隔离后的测试可以无冲突地并行运行，CI 流水线总耗时减少 70% 以上。
- 故障定位效率：测试失败时，100% 确定是数据库逻辑问题，而非外部依赖异常，排查时间缩短 80%。
课程提示： 依赖隔离不是"偷懒"或"降低测试质量"，而是将测试的关注点精确聚焦到 PostgreSQL 自身的行为上。外部系统的集成测试应单独在专门的集成测试套件中执行，与数据库单元测试严格分离。