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 {    // ... 省略日志和常量定义 ...    public List readFromCsv(Class type, CsvToBeanFilter filter) {        List data = new ArrayList();        try {            // 通过抽象方法获取文件名            Resource resource = new ClassPathResource("data/" + getFileName());            Reader reader = new FileReader(resource.getFile());            ColumnPositionMappingStrategy strategy =                 new ColumnPositionMappingStrategy();            strategy.setType(type);            // 通过抽象方法获取列映射            strategy.setColumnMapping(getColumns());            CsvToBean csvToBean = new CsvToBeanBuilder(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 getData(CsvToBean csvToBean);}

其具体实现 AirportService 如下：

@Servicepublic class AirportService extends CsvService {    // ... 省略其他代码 ...    @Override    protected String getFileName() {        return "airports.csv"; // 实际文件名    }    @Override    protected String[] getColumns() {        return new String[]{"id", "code"}; // 实际列映射    }    @Override    protected List getData(CsvToBean csvToBean) {        List 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 service;    @Mock    private CsvToBean 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 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

39 查看详情

解决方案一：使用 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 service; // 类型保持为抽象类 CsvService    @Mock    private CsvToBean 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 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 expectedData = Collections.singletonList(mockAirport);        Mockito.doReturn(expectedData).when(service).getData(any(CsvToBean.class));        // 调用被测方法        List 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 service;    @Mock    private CsvToBean 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 getData(CsvToBean 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 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 不会抛出异常。

总结与最佳实践

测试抽象类中的非抽象方法，同时控制其抽象方法的行为，是单元测试中的

以上就是JUnit 5与Mockito：在Spring Boot中测试抽象类CSV服务的详细内容，更多请关注创想鸟其它相关文章！