本文目录导读：
模拟外部服务进行功能测试（通常称为服务虚拟化或Mock/Stub）是一个非常常见的需求，尤其是在微服务架构或依赖第三方API的系统中，这样做可以避免测试时的网络延迟、服务不稳定、费用消耗或数据污染。
以下是从策略选择到具体实现的完整指南：
核心策略：选择适合你的“模拟”方式
根据你的测试目标，主要有三种策略（从简单到复杂）：
- 硬编码 Stub（桩）：在代码中直接写死返回结果。
- 动态 Mock（模拟）：使用框架录制或预设行为,可以验证交互。
- 真实模拟服务器：运行一个独立的轻量级服务器,完全模拟外部服务的API。
第一步：确定你需要隔离什么（范围）
在开始模拟前，明确你的测试处于哪个“边界”：
- 单元测试：只测试你的逻辑，不涉及网络，使用 Mock 库替换你的 HTTP 客户端。
- 集成测试：测试你的代码与真实数据库或消息队列的交互，对外部服务使用 Mock。
- 端到端测试：通常是全链路，但如果依赖的服务不可用，可以使用模拟服务器来兜底。
第二步：主流实现方案（按场景分类）
代码层 Mock（适用于单元测试/小型集成测试）
工具：Moq (.NET), Mockito (Java), unittest.mock (Python), Sinon.JS (Node.js)
原理：不调用真实服务，而是拦截调用并返回预设数据。非常快，但只验证你代码的逻辑,不验证网络协议。
Python 示例（使用 unittest.mock）：
假设你的函数调用了第三方天气API：
# your_module.py
import requests
def get_weather(city):
response = requests.get(f"https://api.weather.com/v1/{city}")
return response.json()["temperature"]
# test_your_module.py
from unittest.mock import patch
from your_module import get_weather
def test_get_weather_returns_temperature():
# 1. 创建 Mock 对象，预设返回值
mock_response = MagicMock()
mock_response.json.return_value = {"temperature": 22}
# 2. 用 patch 替换实际的 requests.get
with patch('your_module.requests.get') as mock_get:
mock_get.return_value = mock_response
# 3. 执行测试，不依赖网络
result = get_weather("Beijing")
assert result == 22
# 4. （可选）验证调用是否发生
mock_get.assert_called_once_with("https://api.weather.com/v1/Beijing")
优点：速度快，无网络开销，易于控制边界条件（超时、异常）。 缺点：无法捕获真实网络问题（如DNS解析、TLS握手失败）。
HTTP 代理/ Mock 服务器（适用于集成测试/CI流水线）
工具：MockServer, WireMock, mountebank, Mockoon (UI工具)
原理：运行一个独立进程，监听端口，根据匹配的请求路径/方法/头返回预设的响应。隔离程度高，适合验证HTTP协议。
WireMock（Java/独立运行）示例：
- 启动 WireMock 服务器（通常通过测试注解或Docker启动）。
- 配置 Stub（桩）：
// 当收到 GET /api/user/123 时，返回 200 和 JSON stubFor(get(urlEqualTo("/api/user/123")) .willReturn(aResponse() .withStatus(200) .withHeader("Content-Type", "application/json") .withBody("{\"id\": 123, \"name\": \"Test User\"}")) ); - 修改被测代码：将外部服务的
baseUrl修改为 WireMock 的地址（http://localhost:8080）。 - 运行测试：代码向本地 WireMock 发起请求,得到预设响应。
高级功能：
- 状态验证：测试结束后，验证是否确实有请求到达 Mock 服务器（
verify(postRequestedFor(urlEqualTo("/payment"))...)）。 - 故障注入：模拟超时、500错误、网络延迟（
withFixedDelay(1000)）。 - 请求匹配：不仅匹配URL，还匹配Header、Body（JSON/XML）、查询参数。
优点：真实HTTP交互，可模拟复杂场景（如重试、熔断）。 缺点：需要额外维护一个进程,测试速度比代码Mock慢。
录制/回放（适用于确定行为）
工具：VCR (Ruby), Betamax/Polyglot (Java), pytest-vcr (Python), Polly.js (Node)
原理：第一次测试时，真实访问外部API并录制HTTP请求与响应到一个本地文件（Cassette），后续测试直接从文件中回放,无需网络。
Python 示例（pytest-vcr）：
# test_weather.py
@pytest.mark.vcr()
def test_get_weather():
# 第一次运行：真实请求，保存到 cassettes/test_get_weather.yaml
# 第二次运行：从本地文件读取，不发出任何请求
result = api.get_weather("Beijing")
assert result["temperature"] > -10
优点：配置极简，无需手动编写Stub，测试速度非常快。 缺点：依赖“第一次”的真实调用；如果外部API响应发生了变化，需要删除Cassette并重新录制；难以测试边缘情况。
Docker 容器（适用于完整模拟复杂外部服务）
工具：Testcontainers (Java/Go/.NET/Python), LocalStack (AWS模拟), Azurite (Azure模拟)
原理：启动一个Docker容器，该容器运行一个开源模拟版本的外部服务（如模拟S3、DynamoDB、Azure Blob）。
示例（Testcontainers + Redis）： 如果你依赖Redis，不需要安装Redis,Testcontainers会自动启动：
@Container
private static final GenericContainer<?> redis = new GenericContainer<>("redis:7-alpine")
.withExposedPorts(6379);
@Test
void testCacheStore() {
String address = redis.getHost() + ":" + redis.getMappedPort(6379);
// 现在你的代码连接 localhost:random_port 即可
}
优点：最真实，几乎和线上一样（包括认证、协议细节、配置限制）。 缺点：资源消耗最大（需要Docker），启动速度慢，且通常只适用于有开源模拟的服务（如数据库、消息队列、云服务核心API）。
如何选择？
| 测试类型 | 推荐方案 | 原因 |
|---|---|---|
| 单元测试 | 代码层 Mock（如 Mockito） | 速度最快，隔离最彻底，关注逻辑。 |
| 服务间集成测试 | Mock 服务器（如 WireMock） | 验证HTTP协议交互，可模拟超时和异常。 |
| 对稳定外部API的回归测试 | 录制/回放（如 VCR） | 即获得真实行为，又快速且可离线。 |
| 云服务/数据库/消息队列 | Docker 容器（如 Testcontainers） | 最接近真实环境，避免依赖云服务可用性。 |
最佳实践建议
- 分层测试：不要在单元测试中用 WireMock（太重），也不要在全量集成测试中用代码 Mock（太假）。
- 配置化：将外部服务的 Base URL 放在配置文件中，测试时通过环境变量或配置文件切换（
config.external.url -> http://localhost:1080）。 - 考虑契约测试：如果外部服务是你团队也在开发的，考虑 Pact 等契约测试工具，它比单纯的 Mock 更能保证双方接口一致。
- 清理状态：测试结束后，确保 Mock 服务器的状态被重置（或使用短生命周期的容器）。
通过组合使用这些技术，你可以在不依赖真实网络和第三方服务的情况下，高效、可靠地进行功能测试。
