如何测试依赖其他方法的业务逻辑

本文详解如何通过依赖注入（DI）解耦数据访问与业务逻辑，使服务类可被真实、可控地单元测试，避免滥用 Mockito spy 或对被测类自身 mock，并给出可复用的测试结构与最佳实践。

在单元测试中，当一个方法（如 create()）内部调用多个协作方法（如 validateUniqueFields() 和 filterEntityByNameOrCode()），且这些方法又依赖外部状态（如内存数据库 MemoryDatabase），直接测试会陷入“无法控制依赖行为”的困境——这并非测试本身的问题，而是设计阻碍了可测性。

核心原则是：单元测试应验证被测对象的行为，而非其内部实现细节；而可测性是良好设计的副产品。 原代码将 MemoryDatabase.getInstance() 硬编码为私有静态字段，导致无法在测试中替换数据源，也使得 filterEntityByNameOrCode() 的行为完全由真实数据决定，丧失可控性。

✅ 正确解法：引入依赖注入，将数据访问职责抽象为接口，并通过构造函数注入：

public interface Persistence {
    Set getEntities();
    void add(Entity entity);
}

@Service
public class EntityService implements FilteringInterface {
    private final Persistence db; // 从 new MemoryDatabase() → 改为注入

    public EntityService(Persistence db) {
        this.db = db;
    }

    public EntityDTO create(EntityDTO dto) throws Exception {
        validateUniqueFields(dto);
        Entity entity = Entity.toEntity(dto, "id1");
        db.add(entity);
        return new EntityDTO.Builder(entity).build(); // 注意：Builder 调用需补全
    }

    public void validateUniqueFields(EntityDTO dto) throws Exception {
        Set found = filterEntityByNameOrCode(dto.getName(), dto.getCode(), db.getEntities());
        if (!found.isEmpty()) {
            throw new RuntimeException("Already exists"); // 建议使用自定义异常，而非泛化 Exception
        }
    }
}

这样，测试时即可用 @Mock 模拟 Persistence，精确控制 getEntities() 返回值，从而驱动不同分支执行：

@ExtendWith(MockitoExtension.class)
class EntityServiceTest {

    @Mock private Persistence persistence;
    @InjectMocks private EntityService service;

    @Test
    void shouldThrowWhenNameAlreadyExists() {
        // 给定：内存中已存在同名 Entity
        Set existing = Set.of(new Entity(1L, 1L, "duplicate", "other"));
        when(persistence.getEntities()).thenReturn(existing);

        // 当：尝试创建同名 DTO
        EntityDTO dto = new EntityDTO(null, "duplicate", "newcode");

        // 那么：抛出异常
        assertThrows(RuntimeException.class, () -> service.create(dto));
    }

    @Test
    void shouldCreateSuccessfullyWhenBothUnique() {
        when(persistence.getEntities()).thenReturn(Set.of()); // 空库

        EntityDTO dto = new EntityDTO(null, "unique-name", "unique-code");
        EntityDTO result = service.create(dto);

        assertNotNull(result);
        verify(persistence).add(any(Entity.class)); // 可选：验证是否调用了 add
    }
}

⚠️ 关键注意事项：

• 不要 mock 被测类自身（如 Mockito.mock(EntityService.class)）：这会绕过实际逻辑，失去测试意义；
• 避免 @Spy + when().then() 对被测类方法打桩：它破坏封装，使测试脆弱且难以维护；
• FilteringInterface 中的 default 方法无需 mock —— 它们是无状态工具逻辑，随 EntityService 一同被测试覆盖；
• 异常类型建议升级为 IllegalArgumentException 或自定义 DuplicateEntityException，增强语义并便于上层捕获处理；
• 若未来引入真实数据库，只需提供 JpaPersistence implements Persistence 实现，业务逻辑零修改。

总结：可测性源于松耦合。将“获取数据”和“判断逻辑”分离，并通过接口注入数据源，既符合单一职责与依赖倒置原则，也让每个测试场景能被精准构建、清晰断言。所有 CRUD 方法（update/delete）均可沿用同一模式——统一注入 Persistence，复用相同测试范式。