java tdd的核心是用测试定义功能边界、约束实现路径、推动设计演进，严格遵循“红—绿—重构”节奏，每次只驱动一小段逻辑演进，使测试成为可读的需求快照并用mockito隔离依赖，重构必须在测试通过后立即进行。
Java TDD 的实践核心不是写更多测试，而是用测试来定义功能边界、约束实现路径、推动设计演进。它不依赖工具堆砌，而靠“红—绿—重构”三步节奏的严格执行。
明确每轮只解决一个具体问题
比如开发一个订单折扣计算逻辑，不要一上来就写“满500减60、满1000减120、叠加优惠券”——这会直接导致测试难写、代码难测、失败难定位。正确做法是：
- 先写第一个测试：当订单金额为600时，应返回60元折扣（硬编码通过）
- 再写第二个测试：金额为400时，应返回0；此时原硬编码失效，倒逼你引入判断逻辑
- 接着加第三个测试：金额为1000时，应返回120；这时才自然引出阈值配置或公式抽象
每个测试只驱动一行或一小段逻辑演进，避免跳跃式开发。
让测试成为可读的需求快照
Java中测试方法名和断言要直白表达业务意图，而不是技术动作。例如：
- ✅ shouldReturn60DiscountWhenOrderAmountIs600()
- ❌ testCalculateDiscount()
配合JUnit 5的@DisplayName，还能进一步增强可读性。这样，测试类本身就成了活文档，新成员看几个测试就能理解规则，无需翻需求文档。
用Mockito隔离外部依赖，守住单元边界
真实项目里，订单计算常需查用户等级、调用积分服务、读取促销配置。TDD要求你在写业务逻辑前就预设这些协作对象的行为，而不是等出错再补。例如：
- 用
@Mock声明PointsService和PromotionConfig - 在测试里用
when(pointsService.getAvailablePoints(userId)).thenReturn(200)设定已知响应 - 只验证
OrderCalculator内部如何组合这些输入得出最终价格，不关心远程接口是否真通
这样测试快、稳定、可重复，也迫使你把依赖显式化、接口化，天然支持松耦合设计。
重构不是可选项，是验证安全网
绿色通过后立刻重构：提取重复条件判断为常量、把长if链改为策略枚举、将计算逻辑移到独立方法。关键点在于——每次小改完都必须重新运行全部相关测试。只要测试全过，你就知道行为没变，结构更优了。没有测试覆盖的重构，本质是盲改。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
