JUnit 5与Mockito：在Spring Boot中测试抽象类CSV服务-java教程-PHP中文网

junit 5与mockito：在spring boot中测试抽象类csv服务

本文探讨了在Spring Boot应用中，如何使用JUnit 5和Mockito对包含抽象方法的抽象类进行单元测试，特别是当抽象方法涉及文件路径等外部资源时。文章提供了两种核心策略：利用Mockito的`spy`功能进行局部模拟，以及创建测试专用的子类来覆盖抽象方法，从而有效隔离被测单元并确保测试的准确性。

在Spring Boot应用程序中，我们经常会遇到需要处理抽象类的场景，尤其是在设计通用服务时。例如，一个抽象的CSV服务可能定义了读取CSV文件的通用逻辑，而具体的CSV文件类型（如机场数据、用户数据）则通过抽象方法来提供文件名、列映射等特定信息。对这类抽象类中的非抽象方法进行单元测试时，如何有效地模拟其内部调用的抽象方法，同时避免实际的文件I/O操作，是一个常见的挑战。

考虑以下抽象的 CsvService 类，它负责从CSV文件读取数据：

public abstract class CsvService<T extends CsvBean> {

    // ... 省略日志和常量定义 ...

    public List<T> readFromCsv(Class<T> type, CsvToBeanFilter filter) {
        List<T> data = new ArrayList<>();

        try {
            // 通过抽象方法获取文件名
            Resource resource = new ClassPathResource("data/" + getFileName());
            Reader reader = new FileReader(resource.getFile());

            ColumnPositionMappingStrategy<T> strategy = 
                new ColumnPositionMappingStrategy<>();
            strategy.setType(type);
            // 通过抽象方法获取列映射
            strategy.setColumnMapping(getColumns());

            CsvToBean<T> csvToBean = new CsvToBeanBuilder<T>(reader)                    
                    .withFilter(filter)
                    .build();

            // 通过抽象方法处理数据
            data = getData(csvToBean);
            reader.close();

        } catch (IOException ex) {
            // ... 错误处理 ...
        }
        return data;
    }

    protected abstract String getFileName();

    protected abstract String[] getColumns();

    protected abstract List<T> getData(CsvToBean<T> csvToBean);
}

登录后复制

其具体实现 AirportService 如下：

@Service
public class AirportService extends CsvService<Airport> {

    // ... 省略其他代码 ...

    @Override
    protected String getFileName() {
        return "airports.csv"; // 实际文件名
    }

    @Override
    protected String[] getColumns() {
        return new String[]{"id", "code"}; // 实际列映射
    }

    @Override
    protected List<Airport> getData(CsvToBean<Airport> csvToBean) {
        List<Airport> airports = new ArrayList<>();
        for (Airport bean : csvToBean) {
            Airport airport = new Airport(bean.getId(), bean.getCode());
            airports.add(airport);
        }
        return airports;
    }
}

登录后复制

我们的目标是单元测试 CsvService 中的 readFromCsv() 方法，确保其读取、过滤和数据转换的通用逻辑正确。然而，readFromCsv() 依赖于 getFileName()、getColumns() 和 getData() 这三个抽象方法的具体实现。在单元测试中，我们希望模拟 getFileName() 返回一个虚拟的文件名，而不是让测试去读取一个真实存在的 airports.csv 文件。

初始测试尝试及遇到的问题

一个常见的初始测试设置可能如下：

@ExtendWith(MockitoExtension.class)
class CsvServiceTest {

    private CsvService<Airport> service;

    @Mock
    private CsvToBean<Airport> csvToBean; // 模拟 CSV 解析器

    @Mock
    private CsvToBeanFilter filter; // 模拟过滤器

    @BeforeEach
    void setup() {
        // 直接实例化具体的服务类
        service = new AirportService(); 
    }

    @Test
    void testReadFromCsvLogic() throws IOException {
        // 模拟 filter 行为
        when(filter.allowLine((String[]) any())).thenReturn(true);

        // 模拟 csvToBean 迭代器，提供虚拟数据
        Airport mockAirport = new Airport(101, "DK");
        when(csvToBean.iterator())
            .thenReturn(new ArrayIterator<>(new Airport[]{mockAirport}));

        // 问题：此处调用 readFromCsv() 时，内部的 getFileName() 仍然会返回 "airports.csv"，
        // 导致尝试读取真实文件，而不是我们期望的模拟行为。
        List<Airport> result = service.readFromCsv(Airport.class, filter);

        // 断言结果
        assertThat(result).isNotNull().hasSize(1);
        assertThat(result.get(0).getId()).isEqualTo(101);
        assertThat(result.get(0).getCode()).isEqualTo("DK");
    }
}

登录后复制

上述测试的问题在于，service = new AirportService(); 创建的是一个真实的 AirportService 实例。当 readFromCsv() 方法内部调用 getFileName() 时，它会执行 AirportService 中 getFileName() 的实际实现，即返回 "airports.csv"。这会导致 new ClassPathResource("data/" + getFileName()) 尝试加载一个真实的文件，而不是我们希望通过模拟来控制数据源。

为了解决这个问题，我们需要一种机制来模拟 AirportService 实例中的 getFileName() 方法。

面试猫

AI面试助手，在线面试神器，助你轻松拿Offer

查看详情

解决方案一：使用 Mockito.spy 进行局部模拟

Mockito.spy 允许我们对一个真实对象进行“监视”或“部分模拟”。这意味着对象的大部分行为仍然是真实的，但我们可以选择性地模拟其某些方法。这非常适合我们的场景，因为我们希望 AirportService 的大部分逻辑保持不变，只模拟 getFileName() 方法。

创建 Spy 对象： 将 setup() 方法中的 service 实例化方式改为 Mockito.spy(new AirportService())。
模拟特定方法： 使用 Mockito.doReturn().when() 语法来模拟 getFileName() 方法的返回值。这种语法对于 spy 对象非常重要，因为它避免了在调用 when(service.getFileName()) 时实际执行真实方法。

修改后的测试代码如下：

@ExtendWith(MockitoExtension.class)
class CsvServiceTest {

    private CsvService<Airport> service; // 类型保持为抽象类 CsvService

    @Mock
    private CsvToBean<Airport> csvToBean;
    @Mock
    private CsvToBeanFilter filter;

    @BeforeEach
    void setup() {
        // 使用 Mockito.spy 创建 AirportService 的监视对象
        service = Mockito.spy(new AirportService()); 
    }

    @Test
    void testReadFromCsvLogicWithSpy() throws IOException {
        // 模拟 getFileName() 方法，使其返回一个虚拟文件名
        // 注意：此处需要返回一个 ClassPathResource 能够找到的资源，
        // 或者进一步模拟 Resource 和 Reader，但更简单的做法是让 getFileName()
        // 返回一个我们能控制其内容的路径，例如一个内存中的文件路径或者一个空的/测试用文件。
        // 为了简化，我们可以假设 getFileName() 只是返回一个字符串，而实际的 Resource
        // 构造和文件读取逻辑会在 readFromCsv() 中发生，我们可能需要更深层次的模拟。
        //
        // 更直接的思路是，如果 getFileName() 返回一个空字符串或一个不存在的文件名，
        // 那么 readFromCsv() 可能会抛出 IOException。
        //
        // 针对此问题，更好的做法是模拟 Resource 和 Reader，或者让 getFileName()
        // 返回一个指向测试资源目录下的一个小型、可控的测试文件。
        // 但如果目标是完全避免文件I/O，则需要模拟 Resource 和 FileReader。
        //
        // 鉴于原始问题是关于 mocking getFileName()，我们先关注这一点。
        // 如果要完全避免文件I/O，则需要模拟 ClassPathResource 和 FileReader。
        // 
        // 简化起见，我们假设 readFromCsv() 的 Resource 和 Reader 也可以被模拟，
        // 或者 getFileName() 返回一个虚拟路径，然后捕获 IOException。
        // 
        // 更好的模拟方式是，让 getFileName() 返回一个虚拟路径，然后通过 Mockito
        // 模拟 ClassPathResource 和 FileReader 的行为。
        //
        // 为了使这个单元测试有效，我们必须模拟 ClassPathResource 和 FileReader。
        // 这意味着 readFromCsv() 方法内部的 Resource 和 Reader 实例化也需要被控制。
        // 然而，readFromCsv() 内部直接 new 了这些对象，这使得它们难以模拟。
        //
        // **修正思路：** 如果要测试 readFromCsv() 的核心逻辑，而不涉及文件系统，
        // 那么 getFileName() 的返回值应该是一个虚拟值，并且 Resource 和 Reader 
        // 的创建过程也应该被模拟或替换。由于 readFromCsv() 直接 `new ClassPathResource`
        // 和 `new FileReader`，这使得直接模拟这些内部创建的对象变得困难。
        //
        // **更实际的模拟方案是：** 将 `Resource` 和 `Reader` 的创建抽象出来，
        // 或者将它们作为依赖注入。但如果不能修改 `CsvService`，
        // 那么 `spy` 只能模拟 `getFileName()`。
        //
        // 让我们假设 `readFromCsv` 方法的目的是测试其在给定 `Reader` 情况下的逻辑。
        // 如果我们不能修改 `readFromCsv` 来注入 `Resource` 或 `Reader`，
        // 那么测试 `readFromCsv` 就不可能完全脱离文件 I/O。
        //
        // 原始问题是想“mock it and read the provided airport data via stub”，
        // 这意味着我们希望 `readFromCsv` 内部的 `Reader` 是一个模拟的 `Reader`，
        // 而不是从文件系统读取。
        //
        // 解决方案是模拟 `getFileName()`，然后让 `readFromCsv` 内部的 `Resource`
        // 和 `Reader` 的行为也得到控制。这通常需要更复杂的 PowerMock 或修改代码结构。
        //
        // **最直接的解决方案是，如果 `getFileName()` 返回一个不存在的文件名，
        // 那么 `resource.getFile()` 会抛出 `FileNotFoundException` 或 `IOException`。
        // 我们可以测试这个异常路径。**
        //
        // **如果一定要模拟 `Reader` 的内容，那么 `readFromCsv` 方法需要重构以接受 `Reader`
        // 作为参数，或者 `CsvService` 内部需要一个工厂方法来创建 `Reader`。**
        //
        // **鉴于原始答案只提到了 mocking `getFileName()`，我们聚焦于此。**
        //
        // 如果我们只模拟 `getFileName()`，那么 `readFromCsv` 仍然会尝试加载一个文件。
        // 为了让 `readFromCsv` 不进行实际文件读取，并且能够使用 `csvToBean` 的模拟数据，
        // 我们需要确保 `reader` 对象是模拟的。
        //
        // 这通常意味着 `readFromCsv` 方法应该接受一个 `Reader` 参数，或者 `CsvService` 
        // 有一个方法来创建 `Reader`，这个方法可以被子类或 `spy` 模拟。
        //
        // **如果不能修改 `CsvService`，那么测试 `readFromCsv` 且完全避免文件 I/O 是困难的。**
        //
        // **然而，原始问题和答案都指向模拟 `getFileName()`。**
        // **假设 `CsvToBeanBuilder` 能够从一个模拟的 `Reader` 构建。**
        //
        // **进一步思考：** 原始测试中已经 `mocked CsvToBean<Airport> csvToBean`。
        // 如果 `readFromCsv` 能够使用这个模拟的 `csvToBean`，那么它就不需要实际的 `Reader`。
        // 但 `readFromCsv` 内部会创建 `CsvToBeanBuilder`，然后 `build()`。
        //
        // **这揭示了原始 `CsvService` 的一个设计问题：** 紧耦合了 `ClassPathResource` 和 `FileReader`。
        //
        // **如果目标是测试 `readFromCsv` 的 *核心逻辑*（即 `CsvToBeanBuilder` 的配置，
        // `getData` 的调用），那么我们需要模拟 `CsvToBeanBuilder` 的行为。**
        //
        // **重新审视问题：** "But the test is always read the CSV file as it retrieved via `getFileName()` method (the file in the project). But I want to mock it and read the provided airport data via stub."
        //
        // 这意味着它想控制 `CsvToBeanBuilder` 的输入。
        //
        // **最直接的解决方案是：** 如果 `CsvService` 无法修改，那么我们需要模拟 `CsvToBeanBuilder`。
        // 但是 `CsvToBeanBuilder` 是在 `readFromCsv` 内部 `new` 出来的，难以模拟。
        //
        // **唯一能直接模拟的，且在原始答案中提到的，是 `getFileName()`。**
        // 如果 `getFileName()` 返回一个我们控制的测试文件路径，那么 `readFromCsv` 
        // 会去读这个测试文件。
        //
        // **假设我们可以提供一个小的、包含测试数据的 `ClassPathResource`。**
        //
        // 让我们修正 `getFileName()` 的模拟，使其返回一个指向测试资源的路径。
        // 例如，在 `src/test/resources/data/` 下创建一个 `mock_airports.csv` 文件。
        //
        // ```csv
        // id,code
        // 101,DK
        // ```

        // 模拟 getFileName() 方法，使其返回一个指向测试资源的路径
        Mockito.doReturn("mock_airports.csv").when(service).getFileName();
        // 模拟 getColumns() 方法，因为 readFromCsv() 也会调用它
        Mockito.doReturn(new String[]{"id", "code"}).when(service).getColumns();

        // 模拟 getData() 方法，使其返回我们期望的解析结果
        // 这一步至关重要，因为我们不能直接模拟 CsvToBeanBuilder 内部的 Reader。
        // 通过模拟 getData()，我们控制了 readFromCsv() 最终返回的数据。
        // 这样，readFromCsv() 内部的实际文件读取和 CsvToBean 解析过程
        // 就不再影响最终结果，因为 getData() 已经被模拟。
        Airport mockAirport = new Airport(101, "DK");
        List<Airport> expectedData = Collections.singletonList(mockAirport);
        Mockito.doReturn(expectedData).when(service).getData(any(CsvToBean.class));

        // 调用被测方法
        List<Airport> result = service.readFromCsv(Airport.class, filter);

        // 断言结果
        assertThat(result).isNotNull().hasSize(1);
        assertThat(result.get(0).getId()).isEqualTo(101);
        assertThat(result.get(0).getCode()).isEqualTo("DK");

        // 验证 getFileName(), getColumns(), getData() 是否被调用
        Mockito.verify(service).getFileName();
        Mockito.verify(service).getColumns();
        Mockito.verify(service).getData(any(CsvToBean.class));
    }
}

登录后复制

注意事项：

此方法通过 spy 模拟了 getFileName() 和 getColumns()，使其返回测试所需的值。
更重要的是，我们模拟了 getData() 方法。这意味着 readFromCsv() 内部的 CsvToBeanBuilder 仍然会尝试从 mock_airports.csv 文件读取（如果该文件存在于 src/test/resources/data/ 目录下），但 getData() 的模拟确保了 readFromCsv 最终返回的是我们预设的模拟数据，从而隔离了 readFromCsv 的核心逻辑与实际文件I/O。
如果 mock_airports.csv 不存在或格式错误，readFromCsv 内部仍可能抛出 IOException。为了完全避免文件I/O，通常需要将 Resource 和 Reader 的创建抽象化，以便在测试中注入模拟对象。然而，在不修改 CsvService 结构的前提下，模拟 getData() 是一个有效的折衷方案。

解决方案二：创建测试专用的子类

另一种方法是创建一个专门用于测试的 AirportService 子类。在这个子类中，我们可以重写 getFileName() 方法，使其返回一个虚拟或指向测试资源的路径。

创建内部测试类： 在测试类内部定义一个静态嵌套类，它继承自 AirportService。
重写抽象方法： 在这个测试子类中，重写 getFileName()、getColumns() 和 getData() 方法，提供测试所需的行为。

修改后的测试代码如下：

@ExtendWith(MockitoExtension.class)
class CsvServiceTest {

    private CsvService<Airport> service;

    @Mock
    private CsvToBean<Airport> csvToBean; // 模拟 CsvToBean，虽然这里不再直接使用，但保留以示通用性
    @Mock
    private CsvToBeanFilter filter;

    // 定义一个测试专用的 AirportService 子类
    static class TestAirportService extends AirportService {
        @Override
        protected String getFileName() {
            return "mock_airports.csv"; // 返回一个测试用的文件名
        }

        @Override
        protected String[] getColumns() {
            return new String[]{"id", "code"}; // 返回测试用的列映射
        }

        // 重写 getData()，使其返回模拟数据，避免实际解析
        @Override
        protected List<Airport> getData(CsvToBean<Airport> csvToBean) {
            // 这里可以直接返回硬编码的测试数据
            return Collections.singletonList(new Airport(101, "DK"));
        }
    }

    @BeforeEach
    void setup() {
        // 实例化测试专用的子类
        service = new TestAirportService(); 
    }

    @Test
    void testReadFromCsvLogicWithTestSubclass() throws IOException {
        // 模拟 filter 行为 (如果 readFromCsv() 内部的 CsvToBean 实际被调用)
        when(filter.allowLine((String[]) any())).thenReturn(true);

        // 调用被测方法
        List<Airport> result = service.readFromCsv(Airport.class, filter);

        // 断言结果
        assertThat(result).isNotNull().hasSize(1);
        assertThat(result.get(0).getId()).isEqualTo(101);
        assertThat(result.get(0).getCode()).isEqualTo("DK");
    }
}

登录后复制

注意事项：

这种方法通过创建测试专用的子类，完全控制了 getFileName()、getColumns() 和 getData() 的行为，无需使用 Mockito.spy。
getData() 的重写同样是关键，它确保了 readFromCsv() 最终返回的是我们预设的模拟数据，从而避免了实际的文件解析过程。
这种方法的好处是测试代码更加清晰，没有运行时模拟的开销，且更符合面向对象的设计原则（通过继承来改变行为）。
同样，mock_airports.csv 文件仍然需要在 src/test/resources/data/ 目录下存在，以便 new ClassPathResource 不会抛出异常。