答案。

与外部服务的测试隔离性是可靠自动化的必要条件。

问题历史： 早期的自动化系统常常受到外部 API 和数据库的影响，这些服务通常不可用或返回意外的数据。没有隔离的自动化测试结果无法重现：闪烁、因外部问题导致的崩溃以及随机故障。

问题：

外部服务通常不稳定：可能更改合同，数据可能缺失或测试引发副作用。
需要控制（“固定”）外部响应以确保结果的可预测性。
响应慢，以及无法在本地或 CI 中重现场景。

解决方案：

使用“模拟”和“存根”——模拟外部 API 响应的本地占位符。常用的工具有 WireMock（Java）、httpmock（Python）、MockServer、TestContainers。
通过内存中的解决方案或在每个测试之前清除并重新填写的固定数据来模拟数据库。

将测试数据的 ID 提取到变量中，以便测试能够并行执行而不会“互相覆盖”。

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # 在实际测试中，响应将返回给模拟服务器
    # 此处调用 requests.post 和 assert ...

关键特性：

使用模拟服务器来模拟第三方依赖。
状态的清洁：在测试之前/之后清除数据（设置/拆卸）。
测试实体的标识符隔离。

设置陷阱的问题。

在每次运行中，通过真实服务进行集成测试是否必要？

不是的。可以定期使用模拟/存根，而将集成测试单独运行，频率较低且有控制。

使用真实的外部 API 的测试是否总是提供更可靠的结果？

不是的。相反，它们的稳定性更差，可能因合作伙伴那一边的更改而崩溃。持续的闪烁测试会降低管道的质量。

可以使用相同的测试数据进行并行的外部服务自动测试吗？

不可以。这可能导致冲突、竞争和不稳定。标识符和状态必须在测试/流中是唯一的。

常见错误和反模式

不清除或隔离测试数据。
即使是单元测试也使用真实 API。
无根据地缩短等待时间（timeout），导致假失败。
未考虑第三方 API 的更改（同时破坏所有测试）。

生活中的例子

负面案例

公司决定为了速度在真实的第三方 API（支付网关）上运行所有自动测试。多次测试被禁止，限制开始生效，必须恢复访问，数据“流入”真实报告中，出现虚假触发。

优点：

与真实服务的快速集成。

缺点：

操作方的更改破坏了测试，浪费时间和金钱，测试垃圾出现在“生产”服务中，重现的复杂性。

正面案例

设置了 MockServer 和虚拟的内存数据库。在每个测试之前，状态被重置，数据是唯一的。真实的集成测试单独且较少进行。