# 1. TDD 的 Red-Green-Refactor 循环中每个阶段的关键纪律是什么？违反'最小实现'原则会导致什么后果？ A Green 阶段应尽量实现所有可能的功能 B Refactor 阶段不需要测试保障 C Red 阶段先写失败测试，Green 阶段用最小实现通过，Refactor 阶段在测试保障下重构，违反最小实现会引入过度设计风险 ✓ 正确答案 D TDD 循环中不需要失败测试
# 2. Arrange-Act-Assert(AAA)模式如何保证单元测试可读性？Given-When-Then 变体与 AAA 有何异同？ A AAA 与 Given-When-Then 结构完全不同 B Given-When-Then 只能用于单元测试 C AAA 模式不需要 Assert 段 D AAA 用 Arrange/Act/Assert 三段保证可读性，Given-When-Then 与之结构对应，只是更偏业务语言、常用于验收测试 ✓ 正确答案
# 3. TDD 中测试替身的使用时机，何时引入 Mock、何时用真实依赖，过度 Mock 的风险是什么 A 所有依赖都应使用 Mock 替代 B Mock 验证的是行为结果而非调用方式 C 外部慢/不稳定/难控制的依赖用 Mock 隔离，简单稳定的内部依赖用真实对象，过度 Mock 会导致测试与实现耦合、失真 ✓ 正确答案 D 过度 Mock 不会影响测试有效性
# 4. 为什么 TDD 在遗留代码(Legacy Code)中难以直接应用？请说明'接缝(Seam)'概念及渐进引入 TDD 的策略。 A 遗留代码可以直接使用 TDD 标准流程 B 遗留代码难以直接 TDD，需通过接缝引入可替换点、先补特征化测试建立基线，再渐进重构以引入 TDD ✓ 正确答案 C 接缝与可测性无关 D 遗留代码无需补测试
# 5. 单元测试命名规范（如 MethodName_StateUnderTest_ExpectedBehavior）为何重要？好的测试命名如何替代注释和文档？ A 测试命名不重要，随便取即可 B 测试命名只影响美观 C 测试命名无法反映行为 D 好的测试命名（如方法_状态_期望行为）让测试意图一目了然，可定位问题，并以可执行形式替代注释与文档 ✓ 正确答案
# 6. 测试覆盖率（行覆盖/分支覆盖/路径覆盖）的合理目标如何设定？为什么'100%覆盖率'不等于'充分测试'？ A 100% 覆盖率就代表测试充分 B 覆盖率只反映代码被执行程度，不反映断言质量，100% 覆盖仍可能漏检，且可被低价值测试刷分，需结合行为验证综合评估 ✓ 正确答案 C 行覆盖与分支覆盖完全等价 D 覆盖率越高测试一定越好
# 7. TDD 中'测试先行'如何驱动更好的接口设计？请举例说明先写测试如何暴露过度耦合问题。 A 测试先行会让接口设计更复杂 B 测试先行从使用者角度设计 API，测试难以编写常暴露依赖耦合，从而驱动重构为低耦合、易测试的接口 ✓ 正确答案 C 测试先行与接口设计无关 D 测试会隐藏耦合问题
# 8. TDD 在纯函数、业务逻辑与 IO 边界三种代码形态下的实践差异与节奏调整 A 所有代码形态的 TDD 难度相同 B 纯函数最易 TDD、业务逻辑居中、IO 边界需用替身隔离且最慢，应把 IO 与业务逻辑分离以提升可测性 ✓ 正确答案 C IO 边界代码无需测试 D 纯函数无法用 TDD
# 9. 契约先行的 TDD，在接口开发中先写消费者契约再实现，如何保证前后端并行？ A 契约先行要求前后端必须顺序开发 B 先定义并写成可执行契约，前端用 Mock 并行、后端按契约实现并跑契约测试，可保证前后端并行开发且接口一致 ✓ 正确答案 C 契约只是文档，无法执行 D 契约先行与 TDD 无关
# 10. TDD 在 AI 生成代码场景的应用，先写测试再让 AI 实现，如何用测试约束生成质量？ A 先写测试再让 AI 实现，用测试作为验收标准约束生成质量，并通过红绿反馈迭代，但需人工保证测试有效并补充验证 ✓ 正确答案 B 应让 AI 先写代码再补测试 C AI 生成的代码无需测试 D 测试会限制 AI 的全部能力，应取消
# 11. 红-绿-重构循环的执行细节，最小失败测试如何写、重构阶段的安全保障（重构前先有测试），与 TDD 节奏的常见误区？ A 应一次性写覆盖多个行为的测试 B 重构前不需要测试也可保证安全 C Red 阶段写最小失败测试、Green 用最小实现、Refactor 在测试安全网下进行；常见误区是后补测试、过度实现、跳过重构 ✓ 正确答案 D 测试失败无需关注原因
# 12. 特征化测试（Characterization Test）在遗留系统的作用，如何为无测试代码生成"现状快照"测试，重构前的基线价值？ A 特征化测试验证代码应当的行为 B 特征化测试无法辅助重构 C 特征化测试只能用于新代码 D 特征化测试把无测试代码的当前实际行为固化为现状快照，在重构前建立基线，防止重构无意改变行为 ✓ 正确答案
# 13. TDD 与 CI 的配合，红绿灯节奏如何融入 CI 门禁，测试耗时与反馈速度如何优化（测试分层、并行）？ A TDD 与 CI 完全无关 B CI 门禁应执行最慢的全量测试 C 把 TDD 红绿灯节奏融入 CI 门禁，测试通过作为硬要求，并通过测试分层、并行、影响分析、缓存优化反馈速度 ✓ 正确答案 D 测试耗时不影响 TDD 节奏
# 14. 单元测试中'一个测试只验证一个行为'原则与测试执行效率之间如何权衡？ A 每个测试必须且只能有一个断言 B 该原则必须以牺牲所有效率为代价 C 应把所有断言合并到一个测试提升效率 D 一个测试聚焦一个行为，但可合并相关断言、用参数化减少重复，在失败可定位与执行效率间平衡 ✓ 正确答案
# 15. TDD 与 BDD(Behavior-Driven Development)的关系是什么？BDD 在 TDD 基础上增加了哪些协作维度？ A BDD 与 TDD 完全无关 B BDD 是 TDD 的协作化扩展，在测试先行基础上增加业务语言、三方协作、可执行规格与需求澄清等协作维度 ✓ 正确答案 C BDD 只用于单元测试 D BDD 替代了 TDD 的所有技术
# 16. TDD 与测试金字塔的关系，TDD 产出的单测如何服务于金字塔底层的快速反馈？ A TDD 与测试金字塔无关 B 金字塔底层不需要 TDD 产出的单测 C TDD 产出的测试都属于 E2E 层 D TDD 产出金字塔底层的单元测试，这些单测快速、可定位、构成回归安全网，是底层快速反馈的引擎 ✓ 正确答案
# 17. TDD 的形式主义陷阱，「先写测试」变成「后补测试」时如何识别并纠正？ A 先写实现再补测试是合法的 TDD B 测试从不需先行 C 后补测试与 TDD 无区别 D 后补测试失去"测试驱动"价值，可通过"测试是否真先行、是否经历过红、是否驱动设计"识别，并回归测试先行纪律纠正 ✓ 正确答案
# 18. TDD 在并发/异步代码上的实践难点，确定性控制与测试替身的配合？ A 并发/异步代码无法测试 B 异步测试无需等待异步完成 C 通过注入可控的调度器、时钟与测试替身，把随机的异步时序变成可编排的确定时序，实现可重复可断言的测试 ✓ 正确答案 D 测试替身不能用于并发测试
# 19. 测试代码的可维护性，测试数据工厂、断言风格（行为 vs 实现细节）与重构测试代码的时机？ A 用测试数据工厂消除重复、断言行为而非实现细节、及时重构测试代码，可保障测试长期可维护 ✓ 正确答案 B 测试代码无需维护 C 断言实现细节有利于维护 D 测试数据工厂会增加维护负担
