TDD 核心实践

• Red-Green-Refactor 三个阶段的关键纪律
• 最小实现原则的重要性
• 违反纪律的后果

TDD 的 Red-Green-Refactor 循环包含三个阶段，每个阶段都有关键纪律。Red（红）阶段：先写一个失败的测试，纪律是"只用最小篇幅写出能反映真实需求的失败测试"，且测试明确针对未实现的行为；Green（绿）阶段：让测试尽快通过，纪律是"用最小实现（最少代码）让测试通过，不做过度的实现"，允许临时性、不够优雅的代码；Refactor（重构）阶段：在测试保障下重构代码、消除重复与坏味道，纪律是"重构后测试仍通过、行为不变"。违反"最小实现"原则的后果：若在 Green 阶段实现超出当前测试范围的功能（猜测性、过度实现），会引入未经验证的代码，增加缺陷风险与维护成本；会把"测试驱动"变成"先写多余代码再补测试"，破坏 TDD 的节奏；还会让实现偏离测试表达的意图，导致后续测试难以驱动正确设计，甚至掩盖设计问题。最小实现让每个测试都"刚好"驱动一小步，保持节奏可控、变更可回退。

TDD 的核心纪律是"一小步一小步走"。最小实现约束"只实现当前测试所需"，避免过度设计；Red 阶段先写失败测试保证"测试驱动而非测试追证"。违反最小实现会破坏循环的节奏与安全性，让测试失去驱动能力。

• AAA 模式的三段结构
• AAA 如何保证可读性
• AAA 与 Given-When-Then 的异同

Arrange-Act-Assert（AAA）模式把单元测试分为三段：Arrange（准备）——设置被测对象的输入、依赖与前置条件；Act（执行）——执行被测的行为；Assert（断言）——验证执行结果是否符合预期。AAA 通过"三段式"结构保证可读性：它把测试的"准备、行动、验证"清晰分离，读者一眼就能看出"测什么输入、触发什么行为、期望什么结果"，避免把逻辑混在一起难以理解；三段式还强制每个测试聚焦一个行为，便于定位失败原因。Given-When-Then 是 BDD 风格的变体：Given（前置条件）对应 AAA 的 Arrange，When（触发动作）对应 Act，Then（预期结果）对应 Assert。二者本质相同，只是 Given-When-Then 用"业务语言"描述，更贴近非技术干系人、常用于验收测试；AAA 更通用、更贴近代码实现。异同在于：结构对应、强调"前置-动作-结果"三段，但 Given-When-Then 更强调业务可读性与协作，AAA 更强调代码层面的清晰隔离。

AAA/Given-When-Then 的共同价值是"结构化、聚焦单一行为"。可读性来自"三段清晰、意图明确"——读者不必逐行推理。选择哪种取决于受众：团队内部用 AAA，需与业务协作时用 Given-When-Then。无论哪种，核心都是"一个测试一个行为、结构清晰"。

• 测试替身的类型
• Mock 与真实依赖的选择时机
• 过度 Mock 的风险

测试替身（Test Double）包括 Stub（桩）、Mock、Fake、Spy 等，用于隔离被测对象与外部依赖。选择时机：当依赖是"外部、慢、不稳定、难以控制"时（如数据库、网络、第三方服务、时间、随机数），应引入 Mock/Stub 来隔离，让测试快速、确定、可控；当依赖是"内部、简单、计算型、稳定"的对象时，应优先使用真实依赖，因为真实依赖能验证真实集成行为，减少测试与实现脱节。过度 Mock 的风险：一是测试与实现过度耦合——Mock 往往验证"调用方式"而非"行为结果"，实现重构时即便行为不变，测试也可能因 Mock 过细而失败，增加维护成本；二是测试失真——Mock 的行为与真实实现不一致时，会掩盖真实缺陷（"假通过"），让测试失去对真实问题的发现能力；三是语义空洞——过度 Mock 让测试变成"验证 mock 被调用"，失去对业务价值的验证。因此应遵循"只 mock 边界依赖、尽量用真实依赖、不 mock 自身"的原则，优先验证行为结果而非实现细节。

测试替身的核心是"该隔离的隔离、该真实的使用"。Mock 的价值在隔离外部不稳定依赖，但过度 Mock 会牺牲测试的真实性与价值。判断标准是"依赖是否带来不确定性/成本"——是则 mock，否则用真实；同时避免 mock 不属于自己协作的第三方对象。

• 遗留代码中 TDD 的难点
• 接缝（Seam）的概念
• 渐进引入 TDD 的策略

TDD 在遗留代码（Legacy Code）中难以直接应用，因为 TDD 要求"先写测试、再实现"，而遗留代码已存在且通常没有测试、耦合度高、可测性差，无法做到"先写测试再实现"——它需要的是"为已有代码补测试"，这与 TDD 的"测试驱动新代码"方向相反。直接对遗留代码写测试，往往因代码难以实例化、依赖纠缠、副作用多而无法编写。接缝（Seam）是 Michael Feathers 提出的概念：指"在不修改代码的前提下，让你能改变代码行为的地方"——即代码中可被替换/注入的点（如可注入的依赖、可 override 的方法、可替换的接口）。通过引入接缝，可以把遗留代码的某个依赖替换为测试替身，从而让代码可被测试。渐进引入策略：先通过接缝为遗留代码补特征化测试（Characterization Test）建立基线 → 用测试保障重构、提高可测性 → 逐步把依赖注入、接缝引入代码 → 在新增/修改代码处用 TDD → 逐步扩展 TDD 覆盖范围。整体是"先建测试基线、再逐步让代码可测、最后用 TDD 驱动新增长"。

遗留代码 TDD 的难点在于"方向反了"：TDD 面向新代码，遗留代码需要的是"先补测试再重构"。接缝是让遗留代码可测的关键。渐进策略的核心是"在测试保障下逐步引入可测结构"，避免一次性大改的风险，让 TDD 在遗留系统上逐步落地。

• 单元测试命名规范的价值
• 命名规范（MethodName_StateUnderTest_ExpectedBehavior 等）
• 命名替代注释和文档

单元测试命名规范重要，因为测试名是测试代码的"文档"，好的命名让测试意图一目了然，无需读实现细节。常见规范如 MethodName_StateUnderTest_ExpectedBehavior（被测方法_状态_期望行为），例如 "Deposit_ValidAmount_IncreasesBalance"；也有行为描述式命名（如 Given_When_Then 风格）。命名规范的价值：一是可读性——名字直接描述"测什么行为、什么输入、什么结果"，读者不用猜；二是可定位——测试失败时，从名字就能判断是哪个行为、哪个场景出了问题；三是可维护——清晰的命名让测试意图明确，重构时不易误改。好的测试命名替代注释和文档：因为测试名本身就是"可执行的需求文档"——它比注释更准确（不会与代码脱节）、比文档更及时（随代码更新）、可在失败时直接指导人理解。当测试名清晰描述行为与预期时，就不需要额外注释解释"这个测试在测什么"，代码与文档的维护成本也随之降低。

命名的本质是"把测试意图显性化"。好的命名是"可执行文档"，比注释、文档更可信、更及时。命名规范（方法_状态_期望行为）让团队用统一语言描述测试，提升可读性与可维护性，这是测试代码可维护性的重要一环。

• 行/分支/路径覆盖的含义
• 覆盖率合理目标的设定
• 100%覆盖率不等于充分测试的原因

测试覆盖率衡量测试对代码的执行程度：行覆盖（语句覆盖）统计被执行的代码行比例，分支覆盖统计条件分支被验证的比例，路径覆盖统计所有可能执行路径被覆盖的比例（最严格但往往成本过高）。合理目标设定：通常按风险与层级设定，如单元测试行覆盖 70-80%、分支覆盖 60-70% 为常见门槛，高危模块（支付、核心逻辑）要求更高；目标应"可达成、有拦截价值"，避免一味追求 100% 导致成本失控。100% 覆盖率不等于充分测试的原因：一是覆盖率只看"执行了多少代码"，不验证"断言是否正确"——覆盖了的代码可能断言很弱或根本没断言，缺陷照样漏检；二是高覆盖可能漏掉关键路径的组合、边界、异常与集成行为；三是覆盖指标可被"刷"——用低价值测试凑覆盖率，掩盖真实测试不足；四是"充分测试"不仅看代码覆盖，还要看需求覆盖、行为验证、缺陷检出率等。因此覆盖率是"必要非充分"的指标，需结合测试有效性与需求覆盖综合评估。

覆盖率是"测了多少"的宽度指标，不是"测得好不好"的质量指标。100% 覆盖只保证"代码被执行过"，不保证"行为被正确验证"。合理的做法是设定可达成且服务于风险的目标，并用断言质量、缺陷检出率等补充评估，避免唯覆盖率论。

• 测试先行驱动接口设计的机制
• 测试暴露过度耦合的方式
• 测试先行的设计反馈

TDD 中"测试先行"能驱动更好的接口设计，因为先写测试本质上是"从使用者的角度设计 API"——测试是第一位的调用者，它迫使你从"如何被使用"而非"如何实现"来思考接口。写测试时，你需要明确输入、输出、依赖与交互，这种"以调用为核心的思考"会暴露接口是否清晰、是否易用、是否耦合过度。举例：若某 Service 的构造函数直接 new 了数据库连接或依赖全局配置，测试要实例化它就必须真实连接数据库、设置全局环境——测试写起来极其困难，这立刻暴露了"直接 new 依赖、全局状态"的过度耦合。此时测试驱动你重构：把依赖改为构造器注入、抽象接口，让依赖可替换，测试才可写。又如若方法内部依耦合了打印、第三方库，测试会难以断言纯粹行为，驱动你把副作用抽离、返回纯数据。总之，测试先行把"耦合带来的痛苦"在写代码前就暴露，迫使你设计出低耦合、易测试、面向使用的接口。

测试先行对设计的作用是"以使用者视角倒逼设计"。当测试难以编写或断言，通常是接口设计出了问题（耦合、隐藏依赖、副作用）。测试先行把这些设计问题提前暴露，推动你重构为可测、解耦、接口清晰的代码，这正是"测试驱动设计"的内涵。

• 三种代码形态（纯函数、业务逻辑、IO 边界）的特征
• TDD 在不同形态下的实践差异
• 节奏调整

TDD 在不同代码形态下的实践差异源于各形态的可测性与确定性不同。纯函数（无副作用、输入输出确定）：最易 TDD，可直接写测试验证输入输出映射，节奏快、覆盖分支容易，是 TDD 最自然的场景。业务逻辑（有状态、有规则、依赖部分上下文）：TDD 需构造业务状态与规则输入，通过注入依赖或构建业务对象来测，重点验证规则与边界，节奏中等，需配合测试数据构造。IO 边界（数据库、网络、文件、外部服务）：最难 TDD，因为 IO 不确定、慢、有副作用，需用测试替身（Mock/Stub）隔离 IO，测试验证"边界逻辑"（如何调用、如何映射结果、如何异常处理）而非真实 IO，节奏较慢，需额外搭建替身与隔离。节奏调整：纯函数可快速连续红绿转换；业务逻辑需在构造状态上花时间、放慢节奏；IO 边界需先设计替身与隔离、再写测试，节奏最慢，且常与其他形态解耦（把 IO 边界与业务逻辑分离，让业务逻辑可纯函数化测试）。总体原则是"把代码塑造成多数为纯函数/业务逻辑、IO 边界最小化"，让 TDD 高效。

TDD 的难易取决于代码的确定性。纯函数最易、业务逻辑居中、IO 边界最难。策略是"解剖"：把 IO 边界与业务逻辑分离，让核心逻辑可测，IO 边界用替身隔离。这样 TDD 集中在价值最高、最易控的部分，节奏也能匹配各形态特性。

• 契约先行（Contract-First）与 TDD 的结合
• 先写消费者契约再实现
• 保证前后端并行

契约先行的 TDD 是在接口/API 开发中，先定义并写"消费者契约"（Consumer Contract），再按契约实现提供方，本质是把"契约"作为接口开发的"测试先行"。流程：先由前后端（消费方与提供方）共同定义接口契约（请求/响应结构、字段、约束、行为），把契约写成可执行的形式（如契约测试、OpenAPI/Schema、契约文件），再让后端按契约实现、前端按契约开发。保证前后端并行：契约先行把"接口约定"从口头变成可执行的契约，前后端无需等对方完成即可并行——前端基于契约用 Mock 或桩服务联调前端行为，后端基于契约实现并运行契约测试验证兼容性；任何一方违反契约，契约测试即失败，从而在未集成前就发现接口不一致。这样"契约先行 + TDD"让接口开发可并行、可验证：契约测试先写（红）、实现后通过（绿），同时保证前端后端各自独立演进而不破坏契约。这是微服务与前后端分离架构下保证并行开发的关键实践。

契约先行 TDD 的核心是"把契约作为可执行的测试先行资产"。它让接口从"文档约定"变成"可验证的约定"，前端用 Mock 并行、后端用契约测试把关，从而在不联调的前提下保证接口一致，是并行开发与测试前置的桥梁。

• AI 生成代码场景下的 TDD 应用
• 先写测试再让 AI 实现
• 用测试约束 AI 生成质量

TDD 在 AI 生成代码场景的应用，是"先写测试、再让 AI 实现"，把测试作为约束 AI 生成质量的手段。做法：先由人工/团队编写清晰的测试用例（描述期望行为、输入输出、边界与异常），再把测试作为明确需求交给 AI 生成实现，让 AI 的生成代码以"通过测试"为目标。用测试约束质量的方式：一是测试定义了"正确"的边界——AI 生成的代码必须通过测试才算合格，测试成为验收标准，防止 AI 生成"看起来合理但行为错误"的代码；二是测试约束了接口与行为——先写测试固定了接口签名与行为契约，AI 不能随意发挥接口设计；三是通过红绿反馈迭代——AI 生成后跑测试，失败则基于失败信息让 AI 修正、补测试，形成"测试-生成-验证-修正"的循环。但需注意：测试本身要质量高（断言有效、覆盖边界），否则 AI 会"生成能过测试但质量差"的代码；需结合人工评审与额外测试（边界、异常、集成）补充，防止 AI 钻测试空子。

TDD + AI 生成的核心是"让测试成为 AI 的质量护栏"。测试先行把"期望行为"固定下来，AI 只需满足测试即可，从而约束生成质量。但测试的质量决定 AI 质量，需人工保证测试有效、并补充边界与集成验证，防止 AI 生成"过测试的伪正确"代码。

• 最小失败测试的写法
• 重构阶段的安全保障
• TDD 节奏的常见误区

红-绿-重构循环的执行细节：Red 阶段先写"最小失败测试"——用最少的代码表达一个真实需求，让测试因"功能未实现"而失败，且失败原因明确（未实现而非测试错误）；Green 阶段用最小实现让测试通过；Refactor 阶段在测试保障下优化代码。最小失败测试的写法：只针对当前要实现的单一行为，聚焦最小输入、边界或异常，避免一次覆盖多个行为；失败要"可预期"（失败原因清晰），确保测试本身有效。重构阶段的安全保障：重构前必须有测试（且测试通过）作为"安全网"，重构时不断运行测试，若重构破坏行为测试会立即失败，从而保证"重构不改变行为、只改善结构"。常见误区：一是"先写实现再补测试"（变相 TDD，测试失去驱动作用）；二是"测试太大、一次覆盖多个行为"（失败难以定位）；三是"Green 阶段过度实现"（超出测试范围）；四是"跳过 Refactor"（代码质量恶化）；五是"写测试只为通过"（断言过弱、无价值）。避免误区需坚持"小步、单一行为、测试驱动、重构不缺席"。

红绿重构的执行细节都在服务"小步快走、安全可控"。最小失败测试保证方向正确、失败可定位；重构前有测试保证安全。误区多源于"急于求成"（跳步、过度实现、测试低质），坚持 TDD 纪律才能发挥其价值。

• 特征化测试的概念
• 为无测试代码生成现状快照测试
• 重构前的基线价值

特征化测试（Characterization Test，也称表征测试）用于没有测试的遗留代码，其作用是"把代码当前的实际行为固化下来"作为现状快照，而不是验证"应当的行为"。生成方法：对无测试代码先观察其实际输出——用各种输入调用代码、记录返回结果与副作用，把"当前实际行为"断言写成测试，形成"现状快照"测试。这些测试不是基于"正确预期"而是基于"现状事实"，因此即使现状有缺陷，特征化测试也会把缺陷行为固化。重构前的基线价值：在重构遗留代码前，先建立特征化测试作为安全网——它锁定了当前行为，重构时若行为发生任何变化（哪怕是无意的破坏），特征化测试会失败，从而让重构者知道"行为被改变了"。有了基线，重构者可以放心地修改代码结构，因为测试会捕捉行为漂移；同时特征化测试也能帮助理解代码的现有行为，为后续"修正错误行为"（把特征化测试改写成正确预期测试）提供起点。这是遗留代码重构的经典安全策略。

特征化测试的价值在"锁定现状、护航重构"。它不评判行为对错，只固化"当下行为"，让重构者能区分"有意的行为变更"与"无意的破坏"。先建立基线再重构，是遗留代码安全改善的关键；之后可逐步把特征化测试进化成真正的预期测试。

• TDD 红绿灯节奏与 CI 门禁的融合
• 测试耗时与反馈速度的优化
• 测试分层与并行的应用

TDD 与 CI 的配合，是把 TDD 的"红绿灯节奏"（本地先写测试、实现通过、提交）融入 CI 门禁，形成"本地快反馈 + CI 自动把关"的闭环。融入方式：开发者本地做 TDD 红绿循环，提交时 CI 自动运行测试与门禁，若测试失败（红灯）则阻断合并，保证合入主干的代码始终"绿"；CI 门禁把"测试通过"作为硬性要求，让 TDD 的节奏从"个人习惯"升级为"团队强制"。测试耗时与反馈速度优化：CI 门禁的关键是反馈快，否则 TDD 开发者等待会破坏节奏。优化方法：一是测试分层——把快的单元测试前置、慢的集成/E2E 异步或按影响范围跑，门禁以快测试为主；二是并行——把测试分发到多进程/多机器并行执行，缩短总耗时；三是测试影响分析——只跑变更相关的测试子集；四是缓存——输入未变的测试结果复用。通过分层、并行、影响分析、缓存，让 CI 反馈保持快速，让 TDD 的"红绿"节奏在 CI 中保持流畅。

TDD 与 CI 配合的本质是"把本地节奏扩展到团队门禁"。CI 把"测试通过"固化为硬门禁，让 TDD 成为团队纪律；而 CI 反馈速度直接决定 TDD 节奏是否流畅，因此需用分层、并行等优化反馈，避免慢门禁拖垮开发节奏。

• "一个测试只验证一个行为"原则
• 该原则与执行效率的权衡
• 权衡方法

"一个测试只验证一个行为"（One Test, One Behavior）原则指每个测试只验证一个明确的行为/场景，优点是测试意图清晰、失败时定位准确、可维护性强。但严格执行可能导致测试数量庞大、每个测试重复大量准备代码，增加执行开销与编写成本，与执行效率产生权衡。权衡方法：一是"行为"粒度要合理——一个测试可验证一个行为下的多个断言（Assert 多个相关结果），但不应验证多个不相关行为；二是区分"关注点"与"合并"——把"同一行为、同一前置、高度相关"的断言合并到一个测试，减少重复准备；把"不同行为、不同前置"的测试分开，保证可定位；三是用参数化测试（Parameterized Test）减少重复——同一行为的多组数据用参数化合并，既保持意图清晰又减少代码量；四是权衡标准是"失败定位与维护成本"——原则的目的是"失败时快速定位"，若合并断言仍能清晰定位失败，则可适度合并。总体原则是"一个测试聚焦一个行为，但允许相关断言合并、用参数化减少重复"，在可读性与效率间取得平衡。

权衡的本质是"可定位性 vs 执行成本"。原则的价值在于失败定位清晰，代价是测试数量多。合理做法是"行为聚焦 + 相关断言合并 + 参数化复用"，既保留"失败可定位"的核心收益，又避免重复代码拖累效率。不必极端地"一个断言一个测试"。

• TDD 与 BDD 的关系
• BDD 在 TDD 基础上增加的协作维度
• BDD 的具体实践

TDD（测试驱动开发）与 BDD（行为驱动开发）的关系：BDD 是 TDD 的演进与协作化扩展，脱胎于 TDD 但更强调"行为"与"协作"。二者共同点是都用"先写测试/场景再驱动实现"，但 BDD 把关注点从"代码层的行为"提升到"业务层的行为"，并增加了 TDD 缺乏的协作维度。BDD 新增的协作维度：一是业务语言——用 Given-When-Then 的自然语言描述行为，让产品、开发、测试用同一语言沟通，弥合业务与技术鸿沟；二是三方协作——以用户故事与验收场景为核心，产品经理、开发、测试共同讨论并确认"行为规格"，而非仅测试者写测试；三是可执行规格——BDD 场景既是文档又是可执行测试（自动化），实现"活文档"；四是探索会话——BDD 的 Example Mapping 等协作方式在需求阶段澄清歧义。因此 BDD 在 TDD"测试先行"基础上，增加了"业务语言、协作、活文档、需求澄清"等以业务为中心的维度，让测试更贴近业务价值。

BDD 是"TDD + 协作 + 业务语言"的升级。TDD 的测试是"给实现看的"，BDD 的场景是"给所有人看的"——它让测试从工程技术变成业务协作工具。BDD 不替代 TDD，而是扩展其协作维度，让测试驱动更贴近业务价值。

• TDD 与测试金字塔的关系
• TDD 产出的单测与金字塔底层
• 单测提供快速反馈

TDD 与测试金字塔的关系紧密：TDD 是金字塔底层测试（单元测试）的主要生产途径，而金字塔底层为 TDD 提供快速反馈的机制。TDD 产出的单测直接构成金字塔最底层的单元测试——这些测试覆盖单个类/方法的逻辑与分支，速度快、依赖少、定位准，正是金字塔底部"数量多、成本低、反馈快"的组成部分。TDD 产出的单测如何服务快速反馈：一是粒度小、速度快——单测验证最小单元，毫秒级运行，开发者在编码时（本地或 CI 提交阶段）即可获得即时反馈，无需等完整的集成/E2E；二是定位准——单测失败能精确指向具体类/方法，快速定位缺陷；三是回归保护——TDD 过程中积累的单测构成回归安全网，后续改动时快速发现行为变化；四是支撑金字塔结构——丰富的底层单测让团队不必依赖慢速的 E2E 来验证逻辑，从而保证金字塔"底层多、顶层少"的合理结构，维持整体快速反馈。总之 TDD 持续产出高质量底层单测，是金字塔底层快速反馈的引擎。

TDD 与金字塔的关系是"方法支撑结构"：TDD 是"怎么写出底层单测"，金字塔是"这些单测该占多少"。TDD 产出的单测天然满足金字塔底层的"快速、低成本、可定位"要求，既提供了开发期即时反馈，又维持了金字塔的合理结构，避免测试重心上移拖慢反馈。

• TDD 形式主义陷阱
• 先写测试变后补测试的识别
• 纠正方法

TDD 的形式主义陷阱是指"看起来在做 TDD，实际却是先写实现再补测试"——测试在后、实现在前，TDD 变成"后补测试"，失去了"测试驱动设计"的价值。识别方法：一是看测试是否真的"先行"——正常 TDD 是"先出现失败测试、驱动的实现"，若测试是为了"覆盖已写好的实现"而补，则是后补测试；二是看测试的失败是否有意义——真正的 TDD 测试在实现前会失败（红），后补测试通常实现后立即通过、从未经历过"红"；三是看测试是否被实现"牵着走"——后补测试往往顺着实现写法写，断言弱、检验的是实现细节而非行为；四是看测试是否覆盖边界与异常——后补测试常只覆盖"实现的顺利路径"，遗漏边界与异常。纠正方法：一是严格执行"先写失败测试"纪律，让测试先行、经历红绿；二是从行为/需求出发写测试而非从实现出发；三是用"测试是否驱动了设计"自检——若测试没有影响接口设计，可能是后补；四是对后补测试补强断言与边界，并重构为"先测试"的节奏。核心是回归"测试先行、驱动实现"的本质。

形式主义陷阱的本质是"方法正确但顺序颠倒"。识别靠"测试是否真先行、是否经历过红、是否驱动了设计"，纠正靠"回归测试先行纪律、从行为出发写测试"。TDD 的价值在"驱动"，只有测试真正先行才能发挥设计驱动作用。

• 并发/异步代码 TDD 的难点
• 确定性控制
• 测试替身的配合

TDD 在并发/异步代码上的实践难点在于"不确定性"：并发/异步的执行顺序、完成时间、线程调度不可控，导致测试结果不稳（flaky）；同时异步操作（回调、Promise、事件）难以直接断言完成时机。确定性控制是关键：一是控制并发调度——用可控的执行器/线程池（如注入 Executor、用同步/虚拟时钟）把并发调度变成可预测的；二是控制时间——用时钟注入/虚拟时钟控制延时、超时、定时任务，让"等待"变成确定；三是控制完成时机——用异步测试的等待机制（如 await、CompletableFuture、回调钩子）明确等待异步完成再断言，避免"未完成就断言"。测试替身的配合：用可注入的替身代替真实的异步/并发依赖——如用可控制的 Future/CompletableFuture 替身（可通过测试手动完成以触发后续）、用可注入调度器控制线程执行、用消息总线替身记录与触发事件。通过"确定性控制 + 替身",把并发/异步的"任意时序"变成"可编排的时序"，让测试可重复、可断言、可定位。典型如用虚拟时钟验证超时逻辑、用可控 Future 验证异步回调。

并发/异步 TDD 的难点是"不确定性"，解法是"注入确定性"——用可控的调度器、时钟、替身把随机时序变成可编排时序。关键是让被测代码"可注入"确定性依赖（时间、调度、异步返回值），从而在测试中精确控制执行顺序与完成时机。

• 测试代码可维护性的重要性
• 测试数据工厂与断言风格
• 重构测试代码的时机

测试代码的可维护性保障测试能否长期发挥作用，是测试资产的可持续性关键。一是测试数据工厂（Test Data Factory）：用工厂/Builder 集中构造测试数据，避免每个测试重复、冗长地准备数据，数据变化时只需改工厂一个地方，同时用"默认合理值 + 按需覆盖"模式让测试只关心差异字段，提升可读性与维护性。二是断言风格：应断言"行为"而非"实现细节"——断言对用户/外部可见的结果与行为，而非内部实现步骤、调用顺序或私有状态；避免对实现细节的断言，因为实现重构时行为不变、测试却因实现细节变化而失败，增加维护成本。三是重构测试代码的时机：当测试出现重复、命名不清、断言晦涩、数据准备冗长、测试与实现耦合时，应重构测试（与产品代码重构一样定期做）；新增测试时若发现已有测试难以复用或结构混乱，也应顺势重构。重构测试的核心是"保持行为验证不变、提升结构与可读性"，让测试代码与产品代码一样保持高质量。

测试可维护性的核心是"测试代码也是产品代码"。用数据工厂消除重复、用行为断言降低耦合、及时重构测试结构，能让测试在需求演进中持续可维护、可靠。反之，测试代码腐烂会导致测试失效、维护成本飙升，最终被弃用。