service-virtualization

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<objective> Mock Stripe at the SDK layer and your tests pass green while production 500s the moment Stripe changes a response field — because the stub was never tied to a contract. This skill picks the right isolation strategy per dependency (in-process mock, HTTP stub, record-replay, fault injection, or ephemeral real service), stubs at the HTTP layer so tests survive SDK upgrades, and makes the CI run fail when any real call escapes the stubs. </objective>

<objective> 在SDK层Mock Stripe时，你的测试会全部通过，但一旦Stripe修改响应字段，生产环境就会出现500错误——因为Stub从未与契约绑定。本技能针对每个依赖选择合适的隔离策略（进程内Mock、HTTP Stub、记录-重放、故障注入或临时真实服务），在HTTP层进行Stub，确保测试在SDK升级后仍能正常运行，并且当有真实请求绕过Stub时，CI运行会直接失败。 </objective>

Quick Route

快速指南

Situation	Go to
Node/browser test hitting an external HTTP API	MSW → `references/msw.md`
Polyglot CI, complex matching, or you need a standalone stub server	WireMock → `references/wiremock.md`
Dependency is a DB / cache / queue	Testcontainers → `references/testcontainers.md`
Testing timeouts, latency, connection resets	Toxiproxy → `references/toxiproxy.md`
Bootstrapping stubs from a real API, or a multi-step baseline	Record-replay → `references/record-replay.md`
Wiring any of these into GitHub Actions	`references/ci.md`
Not sure which to reach for	Decision Tree (below)

场景	推荐方案
Node/浏览器测试调用外部HTTP API	MSW → `references/msw.md`
多语言CI、复杂匹配规则，或需要独立Stub服务器	WireMock → `references/wiremock.md`
依赖为数据库/缓存/消息队列	Testcontainers → `references/testcontainers.md`
测试超时、延迟、连接重置	Toxiproxy → `references/toxiproxy.md`
从真实API初始化Stub，或需要多步骤基准	记录-重放 → `references/record-replay.md`
将上述工具接入GitHub Actions	`references/ci.md`
不确定选择哪种方案	决策树（见下文）

Discovery Questions

探索问题

Check

.agents/qa-project-context.md

first — if it exists, use it, respect existing mocking conventions, and skip anything answered there. Then:

How many external dependencies does the system call, and which are painful in tests? Rate-limited, slow, flaky, or paid dependencies are the highest-priority virtualization candidates; list payment, email, auth, and third-party data sources.
What testing levels need isolation? Unit tests want fast in-process mocks; integration tests want HTTP-level stubs; E2E wants real or containerized services — the level sets the strategy.
Does the provider offer an official test mode or sandbox? Stripe test mode, Twilio test creds, etc. beat any home-grown stub for fidelity — prefer them where they exist.
Do you have contracts with these dependencies? If yes, contract tests keep stubs in sync; see
```
contract-testing
```
. If no, mocking what you don't own is a known risk (Core Principle 3).
Docker available in CI? No Docker steers you to MSW (in-process); Docker unlocks WireMock, Testcontainers, and Toxiproxy.

首先查看

.agents/qa-project-context.md

——如果存在，请遵循现有Mock约定，并跳过已解答的问题。然后：

系统调用多少个外部依赖，其中哪些在测试中存在问题？ 受速率限制、缓慢、不稳定或付费的依赖是优先虚拟化的对象；列出支付、邮件、认证和第三方数据源。
哪些测试级别需要隔离？ 单元测试需要快速的进程内Mock；集成测试需要HTTP层Stub；端到端测试需要真实或容器化服务——测试级别决定策略。
服务提供商是否提供官方测试模式或沙箱？ Stripe测试模式、Twilio测试凭证等，在保真度上优于任何自制Stub——优先使用此类官方方案。
你与这些依赖是否有契约？ 如果有，契约测试可保持Stub同步；请查看
```
contract-testing
```
。如果没有，Mock非自有依赖存在已知风险（核心原则3）。
CI环境中是否支持Docker？ 不支持Docker时推荐使用MSW（进程内）；支持Docker则可使用WireMock、Testcontainers和Toxiproxy。

Core Principles

核心原则

1. Match the isolation level to the confidence you need. Unit tests can mock aggressively — they test internal logic. Integration tests should use realistic stubs or real services because they test boundaries. E2E should run the closest thing to production that is still reliable.

2. Real services beat fakes when they're fast, free, and reliable. A local PostgreSQL container gives more confidence than a fake and costs little — prefer it. Reserve fakes for dependencies that are slow, unreliable, or paid.

3. Never mock what you don't own without a contract — and prefer the provider's test mode. If you stub Stripe and Stripe changes its response shape, your tests stay green while production breaks. In order of preference: use the provider's official test mode/sandbox (Stripe test mode, Twilio test creds) → an HTTP stub validated by a contract test for drift → a bare stub only when nothing better exists. See

contract-testing

4. Stubs must fail realistically. A stub that always returns 200 never exercises error handling. Every stub needs error variants: 429 rate limits, 500s, timeouts, malformed bodies.

5. One abstraction layer between test and tool. Wrap MSW handlers, WireMock stubs, and Testcontainers setup behind a consistent interface so switching tools doesn't mean rewriting tests.

1. 隔离级别匹配所需的可信度。 单元测试可大胆使用Mock——它们测试内部逻辑。集成测试应使用贴近真实的Stub或真实服务——它们测试边界。端到端测试应使用最接近生产环境且仍可靠的方案。

2. 若真实服务快速、免费且可靠，优先于Fake服务。 本地PostgreSQL容器比Fake服务更可信，且成本极低——优先选择。仅在依赖缓慢、不稳定或付费时使用Fake服务。

3. 无契约时切勿Mock非自有依赖——优先使用提供商的测试模式。 如果你Stub了Stripe，而Stripe修改了响应结构，测试会通过但生产环境会崩溃。优先级顺序：使用提供商官方测试模式/沙箱（Stripe测试模式、Twilio测试凭证）→ 经契约测试验证防漂移的HTTP Stub → 仅在无更好方案时使用基础Stub。请查看

contract-testing

。

4. Stub必须模拟真实失败场景。 始终返回200的Stub永远无法触发错误处理逻辑。每个Stub都需要错误变体：429速率限制、500错误、超时、格式错误的响应体。

5. 测试与工具之间保留一层抽象。 将MSW处理器、WireMock Stub和Testcontainers配置封装在统一接口后，切换工具无需重写测试。

Decision Framework

决策框架

When to use each isolation strategy

何时使用每种隔离策略

Strategy	Speed	Fidelity	Complexity	Best for
In-process mock	Fastest	Lowest	Trivial	Unit tests, isolating internal modules
HTTP stub (MSW)	Fast	Medium	Low	Frontend/Node tests hitting external APIs
HTTP stub (WireMock)	Fast	Medium-High	Medium	Language-agnostic, complex matching rules
Record-replay	Fast after first run	High initially, decays	Medium	Bootstrapping stubs from real APIs quickly
Service fake	Medium	High	High	Stateful dependencies (in-memory DB, fake auth)
Ephemeral real (Testcontainers)	Slower	Highest	Medium	Databases, message queues, caches
Shared real service	Slow	Production-level	Low (to set up)	Staging validation, final pre-deploy check

策略	速度	保真度	复杂度	最佳适用场景
进程内Mock	最快	最低	极低	单元测试、隔离内部模块
HTTP Stub（MSW）	快	中等	低	前端/Node测试调用外部API
HTTP Stub（WireMock）	快	中高	中等	多语言环境、复杂匹配规则
记录-重放	首次运行后速度快	初始保真度高，随时间降低	中等	快速从真实API初始化Stub
服务Fake	中等	高	高	有状态依赖（内存数据库、Fake认证）
临时真实服务（Testcontainers）	较慢	最高	中等	数据库、消息队列、缓存
共享真实服务	慢	生产级	低（搭建成本）	预发布验证、最终上线前检查

Decision tree

决策树

Is the dependency internal to your codebase?
├─ Yes → In-process mock (vi.mock / jest.mock / monkeypatch)
└─ No → Is it a database, cache, or message queue?
         ├─ Yes → Testcontainers (ephemeral real instance)
         └─ No → Is it a third-party HTTP API?
                  ├─ Yes → Does the provider offer a test/sandbox mode?
                  │        ├─ Yes → Use sandbox in staging, MSW/WireMock in CI
                  │        └─ No → MSW or WireMock + contract test for drift detection
                  └─ No → Is it an internal microservice?
                           ├─ Yes → Contract test (Pact) + stub for consumer tests
                           └─ No → Evaluate case by case

Is the dependency internal to your codebase?
├─ Yes → In-process mock (vi.mock / jest.mock / monkeypatch)
└─ No → Is it a database, cache, or message queue?
         ├─ Yes → Testcontainers (ephemeral real instance)
         └─ No → Is it a third-party HTTP API?
                  ├─ Yes → Does the provider offer a test/sandbox mode?
                  │        ├─ Yes → Use sandbox in staging, MSW/WireMock in CI
                  │        └─ No → MSW or WireMock + contract test for drift detection
                  └─ No → Is it an internal microservice?
                           ├─ Yes → Contract test (Pact) + stub for consumer tests
                           └─ No → Evaluate case by case

Tools

工具

Pick MSW as the default for in-process Node/browser tests; WireMock for cross-language CI or standalone stub servers; Prism when the OpenAPI spec is the contract; Mockoon for dev-time exploratory mocking. Heavy code for each lives in

references/

— pointers below.

默认选择MSW用于进程内Node/浏览器测试；WireMock用于跨语言CI或独立Stub服务器；Prism适用于以OpenAPI规范为契约的场景；Mockoon用于开发阶段的探索性Mock。各工具详细代码位于

references/

——以下为指引。

MSW (Mock Service Worker)

MSW 2.x intercepts HTTP at the network layer (Service Worker in the browser, request interception in Node). The default for JS/TS projects. Stub at the HTTP layer (

POST /v1/payment_intents

), never at the SDK method — that decouples the test from the SDK version.

The strongest enforcement seam this skill offers:

setupServer(...).listen({ onUnhandledRequest })

. Set it to

"error"

in CI so any escaped real call fails the run;

"warn"

is fine locally while iterating.

See

references/msw.md

for centralized stateful handlers (payments), the Vitest setup with the CI/local

onUnhandledRequest

switch, per-test timeout/retry overrides, and a full stateful auth flow (create / verify / refresh / revoke via
http.delete
) keyed on a

Bearer

token.

MSW 2.x在网络层拦截HTTP请求（浏览器中使用Service Worker，Node中使用请求拦截）。是JS/TS项目的默认选择。在HTTP层Stub（如

POST /v1/payment_intents

），切勿在SDK方法层Stub——这可使测试与SDK版本解耦。

本技能提供的最强校验机制：

setupServer(...).listen({ onUnhandledRequest })

。在CI中设置为

"error"

，使任何绕过Stub的真实请求导致运行失败；本地迭代时设置为

"warn"

即可。

查看

references/msw.md

获取集中式有状态处理器（支付场景）、支持CI/本地

onUnhandledRequest

切换的Vitest配置、测试级超时/重试覆盖，以及基于

Bearer

令牌的完整有状态认证流程（创建/验证/刷新/通过

http.delete

撤销）。

WireMock

Language-agnostic HTTP stub server (current stable 3.13.2 — 4.0 is beta-only as of mid-2026, stay on 3.x for CI). Runs standalone or as a Docker container. Best for polyglot environments or complex matching rules.

Use priority-based mappings for error scenarios: a

priority: 1

mapping that matches an opt-in header (

X-Test-Scenario: rate-limit

) and returns 429 shadows the default happy-path mapping only when the test asks for it. WireMock also exposes an admin API for programmatic stub creation (

POST /__admin/mappings

), verification (

POST /__admin/requests/count

), and reset (

POST /__admin/mappings/reset

See

references/wiremock.md

for the Docker setup, a response-templated paginated mapping, the priority error mapping JSON, and the drift-detection seam to

contract-testing

(replay a Pact or validate the stub against the OpenAPI spec via Prism).

跨语言HTTP Stub服务器（当前稳定版为3.13.2——截至2026年中期，4.0仅为测试版，CI环境请使用3.x）。可独立运行或作为Docker容器运行。最适用于多语言环境或复杂匹配规则。

使用基于优先级的映射处理错误场景：优先级为1的映射匹配自定义请求头（

X-Test-Scenario: rate-limit

）并返回429，仅当测试触发时才会覆盖默认成功路径映射。WireMock还提供管理API，用于程序化创建Stub（

POST /__admin/mappings

）、验证请求（

POST /__admin/requests/count

）和重置Stub（

POST /__admin/mappings/reset

）。

查看

references/wiremock.md

获取Docker配置、响应模板化的分页映射、基于优先级的错误映射JSON，以及与

contract-testing

的防漂移对接（重放Pact或通过Prism验证Stub与OpenAPI规范一致性）。

Other HTTP mock servers

其他HTTP Mock服务器

Tool	Strengths	When to use
Mockoon	Desktop UI + CLI; OpenAPI import; rule-based responses; lightweight	Dev-time mocking and quick CLI mocks in CI
Hoverfly	Capture-replay (record real traffic, replay deterministically); capture/simulate/modify/synthesize modes	Migrating from a real dependency to a mock — record once, replay forever
Prism	OpenAPI-driven mock server (Stoplight); validates requests + generates responses from spec	OpenAPI-first projects with a published spec
MockServer	Java-based; rich expectation matching; multi-protocol	JVM teams already on MockServer

工具	优势	适用场景
Mockoon	桌面UI+CLI；支持OpenAPI导入；基于规则的响应；轻量	开发阶段Mock，以及CI中的快速CLI Mock
Hoverfly	捕获-重放（记录真实流量，确定性重放）；支持捕获/模拟/修改/合成模式	从真实依赖迁移到Mock的场景——一次记录，永久重放
Prism	OpenAPI驱动的Mock服务器（Stoplight）；验证请求并根据规范生成响应	采用OpenAPI优先方案且已发布规范的项目
MockServer	基于Java；丰富的预期匹配；多协议支持	已使用MockServer的JVM团队

Testcontainers

Spin up real services in Docker for integration tests — containers start before the suite and are destroyed after. Use

@testcontainers/postgresql

11.x and friends. Ports are random; always read them via

getMappedPort()

getConnectionUri()

, never hardcode 5432/6379.

See

references/testcontainers.md

for parallel PostgreSQL + Redis + Elasticsearch startup with wait strategies, the Vitest

globalSetup

wiring (

process.env.DATABASE_URL

testTimeout: 30_000

), and the note on refreshing aging image tags (

elasticsearch:8.12.0

is behind Elastic 9.x).

在Docker中启动真实服务用于集成测试——容器在测试套件启动前启动，测试结束后销毁。使用

@testcontainers/postgresql

11.x及同类库。端口为随机分配；始终通过

getMappedPort()

getConnectionUri()

读取端口，切勿硬编码5432/6379。

查看

references/testcontainers.md

获取PostgreSQL+Redis+Elasticsearch并行启动及等待策略、Vitest

globalSetup

配置（

process.env.DATABASE_URL

、

testTimeout: 30_000

），以及更新过时镜像标签的说明（如

elasticsearch:8.12.0

已落后于Elastic 9.x）。

Toxiproxy (fault injection)

Toxiproxy（故障注入）

ghcr.io/shopify/toxiproxy:2.12.0

sits between your app and a dependency as a TCP proxy and injects latency, bandwidth limits, and connection resets. Point your app at the proxy port, not the real service. Always remove toxics in

afterEach

— they leak across tests otherwise.

See

references/toxiproxy.md

for the compose port mapping, the

createProxy(name, listen, upstream)

wiring (including how the compose

proxy ports map to the real upstream), the helpers with

response.ok

checks on every call, and a latency + connection-reset usage example. For broad resilience/game-day work, go to

chaos-engineering

instead.

ghcr.io/shopify/toxiproxy:2.12.0

作为TCP代理位于应用与依赖之间，可注入延迟、带宽限制和连接重置。将应用指向代理端口，而非真实服务端口。务必在

afterEach

中清除故障配置——否则会影响其他测试。

查看

references/toxiproxy.md

获取Compose端口映射、

createProxy(name, listen, upstream)

配置（包括Compose中

代理端口如何映射到真实上游服务）、每次调用均包含

response.ok

检查的工具函数，以及延迟+连接重置的使用示例。如需大范围弹性/故障演练，请查看

chaos-engineering

。

Record-Replay

记录-重放

Record-replay captures real API responses once and replays them deterministically — good for bootstrapping stubs and for a regression baseline of a multi-step interaction. Implement it with a record-replay library (Hoverfly, Polly.JS, or VCR-style cassettes), not a hand-rolled recorder.

It breaks on dynamic data (timestamps, UUIDs), stateful sequences, and age — recordings go stale within weeks. Always stamp a

recordedAt

and fail the test when a recording is older than 30 days, forcing a re-record.

See

references/record-replay.md

for the cassette format, the

assertFresh()

30-day expiry check, and a replay harness driving a multi-step flow (create order → add items → apply coupon → checkout).

记录-重放功能会一次性捕获真实API响应，然后确定性地重放——适用于初始化Stub和建立多步骤交互的回归基准。使用记录-重放库（Hoverfly、Polly.JS或VCR风格的磁带）实现，切勿自行编写记录器。

该方案在动态数据（时间戳、UUID）、有状态序列和响应时效性方面存在缺陷——记录内容会在数周内过期。务必添加

recordedAt

时间戳，并当记录超过30天时使测试失败，强制重新记录。

查看

references/record-replay.md

获取磁带格式、

assertFresh()

30天过期检查，以及驱动多步骤流程的重放工具（创建订单→添加商品→应用优惠券→结账）。

CI Integration

CI集成

MSW needs zero infrastructure — it intercepts in-process, so CI runs exactly like local; the only rule is to set

onUnhandledRequest: error

in CI (quoted

"error"

in JS) so an escaped real call hard-fails the run. WireMock and Testcontainers need Docker.

Two incompatible port models coexist and must not be mixed in one suite: the docker-compose model publishes fixed ports (a hardcoded

DATABASE_URL=...localhost:5432...

works), while the Testcontainers model uses random ports read via

getMappedPort()

and injected into

process.env

. Pick one per suite.

See

references/ci.md

for the MSW step, the docker-compose GitHub Actions job (

up -d --wait --wait-timeout 120

if: always()

teardown), and the tool-by-constraint table.

MSW无需额外基础设施——它在进程内拦截请求，因此CI运行与本地完全一致；唯一规则是在CI中设置

onUnhandledRequest: "error"

（JS中需加引号

"error"

），使绕过Stub的真实请求直接导致运行失败。WireMock和Testcontainers需要Docker支持。

存在两种不兼容的端口模式，同一测试套件中不可混用：docker-compose模式使用固定端口（硬编码

DATABASE_URL=...localhost:5432...

可行），而Testcontainers模式使用随机端口，需通过

getMappedPort()

读取并注入到

process.env

。每个测试套件仅选择一种模式。

查看

references/ci.md

获取MSW配置步骤、docker-compose GitHub Actions任务（

up -d --wait --wait-timeout 120

、

if: always()

清理），以及基于约束条件的工具选择表。

Anti-Patterns

反模式

1. Mocking everything

1. 所有依赖全Mock

If every dependency is mocked, your tests verify that your mocks work, not that your system works. Use real services for databases and caches (via Testcontainers); only stub external HTTP APIs.

如果所有依赖都被Mock，你的测试仅验证Mock是否有效，而非系统是否正常工作。对数据库和缓存使用真实服务（通过Testcontainers）；仅对外部HTTP API使用Stub。

2. Inconsistent mock behavior across tests

2. 不同测试中Mock行为不一致

One test stubs Stripe as

{ id: "pi_123" }

, another as

{ paymentIntentId: "pi_123" }

— now you have two conflicting versions of reality. Centralize handlers and reuse one response shape across the whole suite (see the shared shape in

references/msw.md

一个测试将Stripe Stub为

{ id: "pi_123" }

，另一个测试Stub为

{ paymentIntentId: "pi_123" }

——此时你拥有两个相互冲突的现实版本。集中管理处理器，在整个套件中复用同一响应结构（查看

references/msw.md

中的共享结构）。

3. Not updating stubs when the API changes

3. API变更时未更新Stub

Your mapping says Stripe returns

{ amount: 1000 }

but the real API now returns

{ amount: 1000, currency: "usd" }

. Tests pass, production fails. Use contract tests to detect drift — see

contract-testing

and the drift seam in

references/wiremock.md

你的映射显示Stripe返回

{ amount: 1000 }

，但真实API现在返回

{ amount: 1000, currency: "usd" }

。测试通过，但生产环境失败。使用契约测试检测漂移——查看

contract-testing

和

references/wiremock.md

中的防漂移对接。

4. Stubbing the wrong layer

4. Stub错误的层级

Mocking

stripe.paymentIntents.create

(the SDK method) couples the test to the SDK version. Stub at the HTTP layer (

POST /v1/payment_intents

) so the test works regardless of HTTP client or SDK version.

Mock

stripe.paymentIntents.create

（SDK方法）会使测试与SDK版本绑定。在HTTP层Stub（

POST /v1/payment_intents

），使测试不受HTTP客户端或SDK版本影响。

5. No error-scenario coverage

5. 未覆盖错误场景

Stubs that always return 200 never exercise retry logic, timeout handling, rate-limit backoff, or error parsing. Every stub needs a corresponding error variant.

始终返回200的Stub永远无法触发重试逻辑、超时处理、速率限制退避或错误解析。每个Stub都需要对应的错误变体。

6. Shared, long-lived mock servers

6. 共享、长期运行的Mock服务器

A shared WireMock instance that multiple CI jobs hit introduces coupling and state leakage. Each test run starts its own isolated stub server.

多个CI任务共享同一WireMock实例会引入耦合和状态泄漏。每次测试运行都应启动独立的Stub服务器。

7. Record-replay without expiration

7. 记录-重放未设置过期时间

Recordings from six months ago reflect an API that no longer exists. Stamp

recordedAt

and fail the test when recordings exceed 30 days, forcing a re-record (see

references/record-replay.md

六个月前的记录反映的是已不存在的API。添加

recordedAt

时间戳，当记录超过30天时使测试失败，强制重新记录（查看

references/record-replay.md

）。

Verification

验证

Prove no real call escaped, smallest check first:

bash

undefined

验证是否有真实请求泄漏，从最小检查开始：

bash

undefined

1. MSW: any unhandled request must hard-fail the suite in CI

1. MSW：CI中任何未处理的请求必须使套件失败

CI=1 npm run test:integration # onUnhandledRequest:"error" → exit 0 means nothing escaped

CI=1 npm run test:integration # onUnhandledRequest:"error" → 退出码0表示无请求泄漏

2. WireMock/Testcontainers: confirm containers are reachable, then teardown leaves nothing

2. WireMock/Testcontainers：确认容器可访问，且清理后无残留

docker compose -f docker-compose.test.yml up -d --wait --wait-timeout 120 && echo OK docker compose -f docker-compose.test.yml down -v

3. Grep CI logs for outbound calls to the real provider's host (should print nothing)

3. 在CI日志中搜索真实服务提供商的主机（应无输出）

grep -iE "api.stripe.com|api.twilio.com" ci-run.log && echo "LEAK" || echo "clean"


A green run under `CI=1` with `onUnhandledRequest:"error"` plus an empty grep for the real host is
the proof that the suite ran fully virtualized.

---

grep -iE "api.stripe.com|api.twilio.com" ci-run.log && echo "LEAK" || echo "clean"


在`CI=1`且`onUnhandledRequest:"error"`的情况下运行测试通过，且搜索真实服务主机无结果，即可证明套件完全虚拟化运行。

---

Done When

完成标准

A dependency isolation strategy is decided and documented for each external dependency (which get MSW/WireMock stubs, which use Testcontainers, which use the provider's sandbox mode).
Stubs cover all critical external dependencies with at least one error path each (4xx/5xx, timeout, or rate limit).
Stubs and mapping files are versioned alongside test code in the same repository.
The suite runs green in CI with
```
onUnhandledRequest: "error"
```
(or the WireMock equivalent), and a grep of CI logs for the real provider host returns nothing.
Any record-replay baseline carries a
```
recordedAt
```
stamp and a 30-day expiry check that fails the test when stale.

为每个外部依赖确定并记录隔离策略（哪些使用MSW/WireMock Stub，哪些使用Testcontainers，哪些使用提供商沙箱模式）。
Stub覆盖所有关键外部依赖，且每个依赖至少包含一条错误路径（4xx/5xx、超时或速率限制）。
Stub和映射文件与测试代码一同版本化存储在同一仓库中。
套件在CI中以
```
onUnhandledRequest: "error"
```
（或WireMock等效配置）运行通过，且CI日志中搜索真实服务主机无结果。
所有记录-重放基准均包含
```
recordedAt
```
时间戳和30天过期检查，过期时测试失败。

Reference Files (in

references/

)

参考文件（位于

references/

）

msw.md — centralized stateful handlers, Vitest setup with the CI/local
```
onUnhandledRequest
```
switch, per-test timeout/retry overrides, and the full create/verify/refresh/revoke auth flow.
wiremock.md — Docker setup, response-templated and paginated mappings, the priority-based error mapping, the admin API, and the contract-drift seam (Pact/Prism).
testcontainers.md — parallel PostgreSQL/Redis/Elasticsearch startup,
```
globalSetup
```
wiring, and the image-tag refresh note.
toxiproxy.md — compose ports,
```
createProxy
```
upstream wiring, helpers with
```
response.ok
```
checks, and a latency + reset usage example.
record-replay.md — tooling choices, the cassette format, the 30-day
```
assertFresh
```
check, and a multi-step replay harness.
ci.md — MSW (zero-infra), the docker-compose GitHub Actions job, the two port models, and the tool-by-constraint table.

msw.md —— 集中式有状态处理器、支持CI/本地
```
onUnhandledRequest
```
切换的Vitest配置、测试级超时/重试覆盖，以及完整的创建/验证/刷新/撤销认证流程。
wiremock.md —— Docker配置、响应模板化和分页映射、基于优先级的错误映射、管理API，以及与契约测试的防漂移对接（Pact/Prism）。
testcontainers.md —— PostgreSQL/Redis/Elasticsearch并行启动、
```
globalSetup
```
配置，以及镜像标签更新说明。
toxiproxy.md —— Compose端口配置、
```
createProxy
```
上游服务配置、包含
```
response.ok
```
检查的工具函数，以及延迟+连接重置的使用示例。
record-replay.md —— 工具选择、磁带格式、30天
```
assertFresh
```
检查，以及多步骤重放工具。
ci.md —— MSW配置（无需基础设施）、docker-compose GitHub Actions任务、两种端口模式，以及基于约束条件的工具选择表。

service-virtualization

Original

Translation

Quick Route

快速指南

Discovery Questions

探索问题

Core Principles

核心原则

Decision Framework

决策框架

When to use each isolation strategy

何时使用每种隔离策略

Decision tree

决策树

Tools

工具

MSW (Mock Service Worker)

MSW (Mock Service Worker)

WireMock

WireMock

Other HTTP mock servers

其他HTTP Mock服务器

Testcontainers

Testcontainers

Toxiproxy (fault injection)

Toxiproxy（故障注入）

Record-Replay

记录-重放

CI Integration

CI集成

Anti-Patterns

反模式

1. Mocking everything

1. 所有依赖全Mock

2. Inconsistent mock behavior across tests

2. 不同测试中Mock行为不一致

3. Not updating stubs when the API changes

3. API变更时未更新Stub

4. Stubbing the wrong layer

4. Stub错误的层级

5. No error-scenario coverage

5. 未覆盖错误场景

6. Shared, long-lived mock servers

6. 共享、长期运行的Mock服务器

7. Record-replay without expiration

7. 记录-重放未设置过期时间

Verification

验证

1. MSW: any unhandled request must hard-fail the suite in CI

1. MSW：CI中任何未处理的请求必须使套件失败

2. WireMock/Testcontainers: confirm containers are reachable, then teardown leaves nothing

2. WireMock/Testcontainers：确认容器可访问，且清理后无残留

3. Grep CI logs for outbound calls to the real provider's host (should print nothing)

3. 在CI日志中搜索真实服务提供商的主机（应无输出）

Done When

完成标准

Reference Files (in references/)

参考文件（位于references/）

Related Skills

相关技能

Reference Files (in
`references/`
)

参考文件（位于
`references/`
）