Spring Boot抽象类及其实现类的单元测试实践

本文探讨了在spring boot应用中如何对抽象类及其具体实现进行单元测试。核心策略是针对具体实现类编写测试用例，并利用mockito等工具模拟其依赖项，以验证抽象逻辑和具体实现方法的正确性，确保代码质量。

1. 抽象类单元测试的挑战与核心策略

在Spring Boot应用开发中，我们常常会利用抽象类来封装通用逻辑，并通过抽象方法定义子类必须实现的行为。例如，CsvService 抽象类定义了从CSV文件读取数据的通用流程，但具体的CSV文件名和数据处理逻辑则由其子类 AirportService 实现。

public abstract class CsvService {
    public List readFromCsv(Class type, CsvToBeanFilter filter) {
        // ... 省略了从资源读取并解析CSV的通用代码 ...
        // 最终会调用 getData(csvToBean) 方法处理解析后的数据
        return new ArrayList<>(); // 简化示例
    }
    protected abstract String getFileName();
    protected abstract List getData(CsvToBean csvToBean); // 假设此方法在 readFromCsv 内部被调用
}

@Service
public class AirportService extends CsvService {
    @Override
    protected String getFileName() {
        return "airport.csv";
    }

    @Override
    protected List getData(CsvToBean csvToBean) {
        List airports = new ArrayList<>();
        for (AirportBean bean : csvToBean) {
            // ... 省略了具体的业务处理逻辑 ...
            airports.add(bean);
        }
        return airports;
    }
}

直接对抽象类 CsvService 进行单元测试是不可能的，因为它不能被实例化，并且包含未实现的抽象方法。因此，核心策略是：通过测试其具体实现类（如 AirportService）来间接验证抽象类中的非抽象逻辑，并直接测试具体类中实现的抽象方法。

对于 AirportService，我们的测试目标是其实现的 getFileName() 方法和 getData() 方法。

2. 单元测试环境准备

在Spring Boot项目中，通常使用 JUnit 配合 Mockito 来进行单元测试。

• JUnit: 提供测试框架和断言方法。
• Mockito: 用于创建和管理模拟对象（mock objects），隔离被测试单元与外部依赖。

为了在测试类中使用 Mockito，可以使用 @ExtendWith(MockitoExtension.class) (JUnit 5) 或 MockitoAnnotations.openMocks(this) (JUnit 4 @Before 方法中)。

• @InjectMocks: 用于自动注入被测试的对象，并将 @Mock 注解的依赖项注入到其中。
• @Mock: 用于创建模拟对象。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;
import org.mockito.junit.jupiter.MockitoExtension;

import java.util.Arrays;
import java.util.List;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.Mockito.*;

// 假设 CsvBean 和 CsvToBean 已经导入
// import com.opencsv.bean.CsvToBean;
// import com.example.model.AirportBean; // 你的数据模型

@ExtendWith(MockitoExtension.class) // JUnit 5
public class AirportServiceTest {

    @InjectMocks
    private AirportService airportService; // 被测试的具体服务

    // 如果 AirportService 自身有其他依赖，则在这里使用 @Mock
    // 例如：@Mock private SomeRepository someRepository;

    // 对于 getData() 方法，我们需要模拟传入的 CsvToBean 对象
    // 但它作为方法参数，不需要在这里声明为 @Mock 字段

    // ... 后续测试方法 ...
}

3. 编写 AirportService 的单元测试

我们将分别测试 AirportService 中 getFileName() 和 getData() 方法。

3.1. 测试 getFileName() 方法

getFileName() 方法是一个简单的具体实现，它只返回一个字符串。测试它非常直接，只需调用该方法并断言其返回值是否符合预期。

    @Test
    void testGetFileName() {
        String fileName = airportService.getFileName();
        assertEquals("airport.csv", fileName, "getFileName() 应该返回 'airport.csv'");
    }

3.2. 测试 getData() 方法

getData() 方法接收一个 CsvToBean 对象，并对其进行迭代处理。为了测试这个方法，我们需要模拟 CsvToBean 对象的行为，使其在迭代时返回我们预设的 AirportBean 列表。

CsvToBean 实现了 Iterable 接口，这意味着我们可以模拟其 iterator() 方法来控制其遍历行为。

    @Test
    void testGetData() {
        // 1. 准备模拟数据：创建预期从 CSV 中解析出的 AirportBean 列表
        AirportBean mockAirport1 = new AirportBean();
        mockAirport1.setCode("LAX");
        mockAirport1.setName("Los Angeles International Airport");
    
    // 假设 AirportBean 还有其他字段，例如：
        // mockAirport1.setCity("Los Angeles");

        AirportBean mockAirport2 = new AirportBean();
        mockAirport2.setCode("JFK");
        mockAirport2.setName("John F. Kennedy International Airport");
        // mockAirport2.setCity("New York");

        List expectedAirportsFromCsv = Arrays.asList(mockAirport1, mockAirport2);

        // 2. 模拟 CsvToBean 对象及其行为
        // 创建一个 CsvToBean 的模拟实例
        CsvToBean mockCsvToBean = Mockito.mock(CsvToBean.class);

        // 当 mockCsvToBean 的 iterator() 方法被调用时，返回我们预设数据列表的迭代器
        when(mockCsvToBean.iterator()).thenReturn(expectedAirportsFromCsv.iterator());

        // 3. 调用被测试方法
        List actualAirports = airportService.getData(mockCsvToBean);

        // 4. 断言结果
        assertNotNull(actualAirports, "返回的机场列表不应为 null");
        assertEquals(2, actualAirports.size(), "返回的机场数量应为 2");

        // 验证返回的数据内容是否与预期相符
        assertEquals("LAX", actualAirports.get(0).getCode());
        assertEquals("Los Angeles International Airport", actualAirports.get(0).getName());

        assertEquals("JFK", actualAirports.get(1).getCode());
        assertEquals("John F. Kennedy International Airport", actualAirports.get(1).getName());

        // 验证 mockCsvToBean 的 iterator() 方法是否被调用了一次
        verify(mockCsvToBean, times(1)).iterator();
    }

3.3. 关于 readFromCsv() 方法的测试考量

CsvService 中的 readFromCsv() 方法包含了文件资源的加载 (new ClassPathResource(getFileName())) 和 CsvToBean 对象的创建逻辑。直接对这些内部创建的对象进行模拟（如 new ClassPathResource()）在标准 Mockito 中是比较困难的，因为它不直接支持模拟构造函数调用。

如果需要对 readFromCsv() 的整个流程进行测试，通常有以下几种方式：

1. 重构代码： 将 Resource 或 InputStream 作为依赖注入到 CsvService 中，这样在测试时就可以轻松模拟这些依赖。这是提高可测试性的最佳实践。
2. 集成测试： 准备一个真实的测试CSV文件放在 src/test/resources 目录下，然后让 readFromCsv() 实际读取这个文件。这更接近集成测试而非纯粹的单元测试。
3. 高级模拟工具： 使用 PowerMockito 等工具可以模拟构造函数和静态方法，但它会增加测试的复杂性，并且通常不推荐过度使用。

在单元测试中，我们更倾向于隔离测试单元。因此，对于 AirportService，我们主要关注其具体实现的 getFileName() 和 getData() 方法，通过模拟 getData() 的输入来验证其逻辑。

4. 注意事项与总结

• 优先测试具体实现类： 抽象类本身无法直接测试，应通过其具体子类来验证其定义的行为和抽象方法的实现。
• 利用 Mockito 隔离依赖： 当具体类的方法依赖于其他服务、数据库访问或复杂对象（如 CsvToBean）时，使用 Mockito 创建模拟对象，控制它们的行为，从而将测试范围限制在当前被测试单元。
• 关注单一职责： 每个测试方法应该只验证被测试单元的一个特定行为或功能。
• 提高可测试性： 对于在方法内部创建的难以模拟的复杂对象（如 new ClassPathResource()），考虑重构代码，将其作为依赖注入，从而提高代码的可测试性和灵活性。
• 区分单元测试与集成测试： 单元测试旨在验证最小代码单元的正确性，而涉及文件系统、网络或数据库等外部资源的测试更适合作为集成测试。

通过上述策略和示例，您应该能够在 Spring Boot 应用中有效地为抽象类及其具体实现编写健壮的单元测试。