三个要点，掌握Spring Boot单元测试

单元测试是软件开发中不可或缺的重要环节，它用于验证软件中最小可测试单元的准确性。结合运用Spring Boot、JUnit、Mockito和分层架构，开发人员可以更便捷地编写可靠、可测试且高质量的单元测试代码，确保软件的正确性和质量。

一、介绍

本文将从与单元测试相关的技术主题开始，在技术部分之后，介绍使用Spring Boot、JUnit和Mockito进行单元测试的实践。

二、测试的关键要素

1.单元

单元测试中的单元一词指的是软件中可以单独测试和处理的最小功能部分，通常是指函数、方法、类或模块等独立的代码片段。

2.用例

用例描述了系统使用特定功能或特性的方式，用于理解、设计和测试软件系统的需求。通常包括用户如何与系统进行交互、对系统的期望以及应该实现的结果等详细信息。

3.边界情况

边界情况指的是软件必须处理的特定场景，这些场景包括意外或边界条件，与典型情况有所不同或被认为是罕见的情况。边界情况可以包括意外用户登录、测试限制、异常输入或其他可能导致系统错误或异常行为的情况。在测试过程中，考虑和测试边界情况是非常重要的，因为它们可以帮助开发人员发现潜在的问题并确保系统的鲁棒性和稳定性。

三、单元测试

单元测试涵盖了我们可以考虑并编写的所有可能性。每个单元必须至少有一个测试方法。测试不是为一个方法编写的，而是为一个单元编写的。

可以按照以下顺序编写单元测试：正常路径/用例、边界情况和异常情况。

这些步骤是必不可少的，这样做可以确保单元以正确的方式处理输入，并生成预期的输出，展现出预期的行为。单元测试是及早发现风险和修复错误的最佳方式。通过单元测试，我们可以预防潜在的意外情况，应对生产代码的变更，确保生产代码能够处理各种情况。简而言之，单元测试确保了生产代码的安全性。

关于单元测试的另一个重要事项是要测试业务逻辑，不是在单元测试中测试基础设施代码，基础设施代码可以在集成测试中进行测试。可以考虑使用一些架构模式（如洋葱架构、六边形架构等）来将业务逻辑与基础设施代码分离。

单元测试的另一个优点是速度快，因为它不需要依赖 Spring ApplicationContext。由于上下文的原因，与单元测试相比，同一测试金字塔中的集成测试速度要慢得多。

1.开始编码

在分层架构项目中，业务代码主要位于服务层。这意味着服务层具有单元，需要进行测试。让我们聚焦于最关键的部分。

以下是一段示例代码：

  @Override
    public String saveUser(User user) {
        validateUser(user);
        try {
            User savedUser = userRepository.save(user);
            return savedUser.getEmail();
        } catch (Exception exception) {
            throw new IllegalArgumentException(E_GENERAL_SYSTEM);
        }
    }

    private void validateUser(User user) {
        if (Objects.isNull(user.getEmail())) {
            throw new IllegalArgumentException(E_USER_EMAIL_MUST_NOT_BE_NULL);
        }
        if (findByEmail(user.getEmail()).isPresent()) {
            throw new IllegalArgumentException(E_USER_ALREADY_REGISTERED);
        }
    }

    @Override
    public Optional findByEmail(String email) {
        return userRepository.findByEmail(email);
    }

上述代码中有两个公共方法和一个私有方法，私有方法可以被视为公共方法的一部分。此外，由于代码的复杂性和功能需求，还存在许多可能的场景需要编写多个测试用例来覆盖各种情况，以确保代码的正确性。

2.注解

@ExtendWith用于将Mockito库集成到JUnit测试中。@Test 标记一个方法，使其成为一个测试方法，测试方法包含指定的测试用例，并由 JUnit 自动运行。

在测试过程中，需要模拟正在测试的类的依赖项。之前提到的原因是，由于 Spring ApplicationContext 不会启动，我们无法将依赖项注入到上下文中。@Mock 用于创建一个模拟的依赖项，而 @InjectMocks 则用于将这些模拟的依赖项注入到被测试类中。

@BeforeEach和@AfterEach可用于在每个方法运行之前和之后执行相应的操作。

@ParameterizedTest 用于使用不同的参数值运行重复的测试用例。通过使用 @ValueSource，可以为方法提供不同的参数值，以便进行多次测试。

3.测试方法的三个主要阶段

• Given: 准备测试用例所需的对象
• When: 执行必要的操作以运行测试场景
• Then: 检查或验证预期结果

doReturn/when 用于确定在给定指定参数时方法的行为方式。但是，由于依赖项是 @Mock，并不会真正执行。

verify 用于检查被测试代码是否按照预期行为执行。如果要测试的方法是 public void 类型，可以使用 verify 进行验证。

断言用于验证预期结果。

 @ExtendWith(MockitoExtension.class)
class UserServiceImplTest {

    @InjectMocks
    private UserServiceImpl userService;

    @Mock
    private UserRepository userRepository;

    private User user;
    public static final String MOCK_EMAIL = "[email protected]";

    @BeforeEach
    void setUp() {
        user = new User();
        System.out.println("init");
    }

    @AfterEach
    void teardown() {
        System.out.println("teardown");
    }

    @ParameterizedTest
    @ValueSource(strings = {"[email protected]", "[email protected]"})
    @DisplayName("Happy Path: save user use cases")
    void givenCorrectUser_whenSaveUser_thenReturnUserEmail(String email) {
        // given
        user.setUserName("mertbahardogan").setEmail(email).setPassword("pass");
        User savedUser = new User().setEmail(email);
        doReturn(savedUser).when(userRepository).save(any());

        // when
        String savedUserEmail = userService.saveUser(user);

        // then
        verify(userRepository,times(1)).findByEmail(anyString());
        verify(userRepository,times(1)).save(any());
        assertEquals(email, savedUserEmail);
    }

    @Test
    @DisplayName("Exception Test: user email must not be null case")
    void givenNullUserEmail_whenSaveUser_thenThrowsEmailMustNotNullEx() {
        // when
        Exception exception = assertThrows(IllegalArgumentException.class, () -> userService.saveUser(user));

        // then
        assertNotNull(exception);
        assertEquals(E_USER_EMAIL_MUST_NOT_BE_NULL, exception.getMessage());
    }

    @Test
    @DisplayName("Exception Test: user is already registered case")
    void givenRegisteredUser_whenSaveUser_thenThrowsUserAlreadyRegisteredEx() {
        // given
        user.setEmail(MOCK_EMAIL);
        Optional savedUser = Optional.of(new User().setEmail(MOCK_EMAIL));
        doReturn(savedUser).when(userRepository).findByEmail(anyString());

        // when
        Exception exception = assertThrows(IllegalArgumentException.class, () -> userService.saveUser(user));

        // then
        assertNotNull(exception);
        assertEquals(E_USER_ALREADY_REGISTERED, exception.getMessage());
    }

    @Test
    @DisplayName("Exception Test: catch case")
    void givenIncorrectDependencies_whenSaveUser_thenThrowsGeneralSystemEx() {
        // given
        user.setEmail(MOCK_EMAIL);

        // when
        Exception exception = assertThrows(IllegalArgumentException.class, () -> userService.saveUser(user));

        // then
        assertNotNull(exception);
        assertEquals(E_GENERAL_SYSTEM, exception.getMessage());
    }

    @Test
    @DisplayName("Happy Path: find user by email")
    void givenCorrectUser_whenFindByEmail_thenReturnUserEmail() {
        // given
        Optional savedUser = Optional.of(new User().setEmail(MOCK_EMAIL));
        doReturn(savedUser).when(userRepository).findByEmail(anyString());

        // when
        Optional user = userService.findByEmail(MOCK_EMAIL);

        // then
        verify(userRepository,times(1)).findByEmail(anyString());
        assertEquals(savedUser, user);
    }
}

UserServiceImpl测试类运行时长为1秒693毫秒。

介绍一款软件开发工具

成功的前端工程师很会善用工具，这些年低代码概念开始流行，像国外的 Mendix，国内的 JNPF，这种新型的开发方式，图形化的拖拉拽配置界面，并兼容了自定义的组件、代码扩展，确实在 B 端后台管理类网站建设中很大程度上的提升了效率。

JNPF开发平台，很多人都用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。

原理是将开发过程中某些重复出现的场景、流程，具象化成一个个组件、api、数据库接口，避免了重复造轮子。因而极大的提高了程序员的生产效率。

官网：http://www.jnpfsoft.com/?csdn，如果你有闲暇时间，可以做个知识拓展。

这是一个基于Java Boot/.Net Core构建的简单、跨平台快速开发框架。前后端封装了上千个常用类，方便扩展；集成了代码生成器，支持前后端业务代码生成，满足快速开发，提升工作效率；框架集成了表单、报表、图表、大屏等各种常用的Demo方便直接使用；后端框架支持Vue2、Vue3。

为了支撑更高技术要求的应用开发，从数据库建模、Web API构建到页面设计，与传统软件开发几乎没有差异，只是通过低代码可视化模式，减少了构建“增删改查”功能的重复劳动。