Java代码易于测试的核心在于设计阶段注重可测性：单一职责、依赖注入、接口隔离、无副作用、短小可预测方法及TDD实践。
让 Java 代码易于测试，核心在于设计阶段就为可测性留出空间，而不是等写完再“补测试”。关键不是写得多，而是结构清晰、职责分明、依赖可控。
明确类的单一职责
一个类只做一件事，并把这件事做好。比如处理用户登录的逻辑，就该独立成 LoginService，而不应混入数据库连接、日志记录或前端跳转。
- 职责越集中，测试用例越聚焦——只需验证输入用户名密码，是否返回成功/失败结果
- 避免在类里直接 new 其他服务（如
new DatabaseUtil()），否则无法替换为模拟对象 - 方法尽量无副作用：不修改外部状态、不依赖静态变量、不调用
System.out.println等不可控操作
用接口隔离外部依赖
把具体实现和使用方解耦。例如，需要查用户，就定义 UserRepository 接口，而不是直接依赖 JdbcUserRepository 类。
- 测试时可用
Mockito.mock(UserRepository.class)快速构造可控的返回值 - 构造方法或 setter 中注入依赖（推荐构造注入），而非在方法内部硬编码创建
- 像时间、随机数这类“外部”行为，也建议封装成接口（如
Clock、RandomGenerator），方便固定测试场景
保持方法短小、可预测、有返回值
测试难，往往是因为方法太长、路径太多、返回值模糊。优先写纯函数式风格的方法：输入确定 → 输出确定。
立即学习“Java免费学习笔记（深入）”；
- 避免 void 方法承担核心业务逻辑（如
processOrder()不返回任何结果），改用OrderResult processOrder(Order order) - 条件分支多时，拆成多个小方法，每个方法对应一种明确路径，单独测试更直观
- 边界情况要显式处理并返回——比如空字符串、负数、null 输入，应明确定义行为（抛异常 or 返回默认值），不能靠“运行时看效果”
配合 TDD 节奏写测试与产品代码
不是先写完所有功能再补测试，而是按“红→绿→重构”节奏推进：
- 先写一个失败的测试（红）：描述你期望的最小行为，比如
assertThat(calculator.add(2, 3), is(5)) - 用最简方式让测试通过（绿）：哪怕只是
return 5;，先满足契约 - 再补充真实逻辑，并确保测试仍通过；接着加更多测试覆盖边界（0、负数、大数等）
- 每次重构前，确保已有测试全绿——这是你敢于优化结构的安全网
