匿名内部类在单元测试中适合快速实现接口或抽象类以做桩，适用于仅需覆盖1–2个方法、无mock框架、接口非函数式等轻量场景，但需实现所有抽象方法且可读性较差。
Java 中匿名内部类在单元测试里做桩（Stub），核心是利用它快速实现接口或抽象类，绕过真实逻辑。适合简单场景，比如只覆盖一两个方法、不需要复用、也不涉及复杂状态。
什么时候该用匿名内部类写桩
适合以下情况：
- 被测类依赖一个接口，但你只想控制其中 1–2 个方法的返回值，其余方法用默认行为（如返回 null、0 或空集合）即可
- 没有现成的 mock 框架（比如项目受限不能用 Mockito），或想避免引入额外依赖
- 测试逻辑极轻量，不值得单独定义一个命名类或使用 lambda（比如接口有多个抽象方法，lambda 不适用）
怎么写：三步写出可用的匿名桩
以常见的 UserService 接口为例：
public interface UserService {
User findById(Long id);
void save(User user);
List<User> findAll();
}
在 JUnit 测试中快速构造一个只“骗过” findById 的桩：
立即学习“Java免费学习笔记（深入）”；
UserService stubUserService = new UserService() {
@Override
public User findById(Long id) {
if (id == 100L) {
return new User(100L, "Mock User");
}
return null;
}
@Override
public void save(User user) {
// 空实现，不执行任何逻辑
}
@Override
public List<User> findAll() {
return Collections.emptyList();
}
};
关键点：
- 必须实现接口所有抽象方法（编译器强制），哪怕只是空方法或返回安全默认值
- 可以在方法体内加简单条件判断，模拟不同输入对应不同输出
- 若接口有 default 方法，无需重写；有 static 方法，也不能在匿名类中覆盖
和 Lambda 的区别：别误用
只有函数式接口（仅含一个抽象方法）才能用 lambda，比如 Runnable、Function。像上面的 UserService 有三个抽象方法，不能用 lambda 替代，否则编译失败。匿名内部类是更通用的“兜底方案”。
注意生命周期与可读性
匿名内部类会隐式持有外部类引用（如果在非静态上下文中创建），可能引发内存泄漏（对单元测试影响小，但需留意）。另外，方法一多，代码容易变长、难维护——这时建议升级为：
- 用 Mockito 的
mock()+when().thenReturn()（推荐主流做法） - 或提取成私有静态辅助类，提高可读性和复用性
匿名内部类桩不是银弹，而是“够用就好”的轻量选择。
