1. 测试驱动开发（TDD）的红-绿-重构循环与工程实践
问题
请详细说明测试驱动开发（TDD）的红-绿-重构（Red-Green-Refactor）循环的具体步骤，以及在实际工程中如何落地 TDD 实践？
考察点
- TDD 三阶段循环的完整流程与每个阶段的目的
- 先写测试再写实现对设计的影响（测试即规格）
- 工程实践中遇到的实际困难（如依赖、时序）与应对
答案
TDD 的核心是一个极短的迭代循环：**Red（红）**阶段先编写一个失败的最小测试，明确表达"期望的行为"，此时因为没有实现，测试必然失败；**Green（绿）**阶段用最简单、最快的方式让测试通过，不追求设计优雅，只求功能正确；Refactor（重构） 阶段在测试保护下消除重复、重构代码，使其达到良好设计。整个循环频率高（通常几分钟一次），保证每一小步都有测试把关。工程实践上，TDD 强制"先想清楚接口再写实现"，从而促使设计以调用方（测试）为导向，天然产生高内聚松耦合的接口；同时依赖注入成为必需，因为测试需要替换依赖。实践中常见挑战包括：对复杂算法或外部依赖不知如何起步，可先用"三角测量"（先测一个简单用例，再补充一个约束用例）逐步逼近；对 I/O 或时序依赖，则通过注入 Clock、Repository、HttpClient 等抽象来隔离。TDD 并非万能，对纯算法、业务规则、序列化逻辑收益最大，对 UI 或探索性代码可降级为"测试先行补充"。
解析
红-绿-重构的本质是把"宏大的测试驱动的设计"拆解为可微验证的微观步骤。每一步的"红"都在验证测试本身有效（能捕捉到缺陷），"绿"保证功能正确，"重构"保证代码质量，三者缺一不可。缺少"红"阶段意味着测试可能永远通过（失效测试），缺少"重构"阶段则会让代码腐化。TDD 的价值并不在于"测得多"，而在于让测试成为驱动设计的规格文档，倒逼出可测试、可替换的架构。
示例代码
// 1. Red：先写一个失败的测试
@Test
void shouldReturnTrueWhenPalindrome() {
assertTrue(isPalindrome("abcba"));
}
// 2. Green：最小实现让测试通过
boolean isPalindrome(String s) {
StringBuilder sb = new StringBuilder(s);
return s.equals(sb.reverse().toString());
}
// 3. Refactor：在测试保护下提取优雅实现
boolean isPalindrome(String s) {
int i = 0, j = s.length() - 1;
while (i < j) {
if (s.charAt(i++) != s.charAt(j--)) return false;
}
return true;
}