Java如何测试私有方法的公共方法

还在苦恼Java中如何测试私有方法？本文为你揭秘最佳实践！核心在于避免直接测试私有方法，而是通过测试调用它们的公共方法来间接验证其行为，从而在保证代码封装性的前提下，确保代码质量。文章以UserService的create方法和checkUsername私有方法为例，详细阐述如何设计测试用例，利用Mockito等Mocking框架模拟依赖项，并断言预期结果和方法调用次数。同时，深入探讨了直接测试私有方法的弊端及其有限的应用场景，助你写出健壮、可维护的单元测试。还在等什么？快来学习Java私有方法测试的正确姿势吧！

本教程探讨了Java中测试包含私有方法的公共方法的最佳实践。核心原则是避免直接测试私有方法，而是通过测试其公共调用者来间接验证其行为。文章将通过一个具体的create方法和私有checkUsername方法的示例，详细阐述如何设计测试用例，利用Mocking框架模拟依赖项，并断言预期结果和方法调用次数，从而在不破坏封装性的前提下确保代码质量。同时，也将讨论直接测试私有方法的弊端及其有限的应用场景。

1. 理解私有方法的测试挑战

在面向对象编程中，私有方法是类的内部实现细节，它们旨在封装逻辑并支持公共方法的行为。根据封装原则，外部不应直接访问私有方法。因此，如何有效地测试这些不可直接访问的私有方法，是单元测试中一个常见的挑战。直接测试私有方法不仅破坏了封装性，也可能导致测试与实现紧密耦合，使得代码重构变得困难。

2. 最佳实践：通过公共方法间接测试私有方法

测试私有方法的正确方法是间接测试。这意味着我们不直接调用私有方法，而是测试调用它的公共方法。通过这种方式，我们验证的是公共方法的整体行为，包括其内部私有逻辑的正确执行。

2.1 核心理念：封装与行为验证

单元测试的目标是验证代码的行为是否符合预期，而不是验证其内部实现细节。当一个私有方法被一个公共方法调用时，它的行为是公共方法整体行为的一部分。因此，只要公共方法的输出或状态变化符合预期，就意味着私有方法也正确执行了。这种方法尊重了封装性，并使得测试更健壮，不易受内部实现变化的影响。

2.2 示例分析：User服务中的create方法

考虑以下UserService及其依赖：

// 假设的User实体类
class User {
    private String username;
    private String password;
    private Long id;

    public User(String username, String password) {
        this.username = username;
    }

    public User(String username, String password, Long id) {
        this.username = username;
        this.password = password;
        this.id = id;
    }

    public String getUsername() { return username; }
    public Long getId() { return id; }
    // ... 其他getter/setter
}

// 假设的UserRepository接口
interface UserRepository {
    boolean existsByUsername(String username);
    User save(User user);
}

// 假设的自定义异常
class UsernameUnavailableException extends RuntimeException {
    public UsernameUnavailableException(String message) { super(message); }
}

class UsernameIsInUseException extends RuntimeException {
    public UsernameIsInUseException(String message) { super(message); }
}

// 待测试的UserService类
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User create(User user) {
        checkUsername(user.getUsername()); // 公共方法调用私有方法
        return userRepository.save(user);
    }

    private void checkUsername(String username) {
        if (username.equals("dummy")) {
            String msg = String.format("Username = '%s is cannot be used!", username);
            throw new UsernameUnavailableException(msg);
        } else if (!userRepository.existsByUsername(username)) {
            return; // 用户名可用
        }

        String msg = String.format("Username ='s%s' is being used by another user!", username);
        throw new UsernameIsInUseException(msg);
    }
}

create方法负责创建用户，它内部调用了私有方法checkUsername来验证用户名的有效性。checkUsername方法有三种可能的行为：

1. 如果用户名是"dummy"，抛出UsernameUnavailableException。
2. 如果用户名已存在，抛出UsernameIsInUseException。
3. 如果用户名可用，则正常返回。

2.3 设计测试用例

我们将为create方法设计测试用例，覆盖checkUsername的所有行为分支：

1. 测试场景1：用户名"dummy"
   • 预期结果：create方法抛出UsernameUnavailableException，且userRepository的任何方法都不被调用。
2. 测试场景2：用户名已存在
   • 预期结果：create方法抛出UsernameIsInUseException，userRepository.existsByUsername被调用一次，userRepository.save不被调用。
3. 测试场景3：用户名可用且成功保存
   • 预期结果：create方法成功返回一个User对象，userRepository.existsByUsername和userRepository.save都被调用一次。

2.4 利用Mocking框架模拟依赖

为了隔离UserService的测试，我们需要模拟其依赖userRepository。Mocking框架（如Mockito）允许我们控制依赖的行为，并验证其交互。

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;

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

class UserServiceTest {

    @Mock // 模拟UserRepository接口
    private UserRepository userRepository;

    @InjectMocks // 将模拟的userRepository注入到UserService实例中
    private UserService userService;

    @BeforeEach
    void setUp() {
        // 初始化所有@Mock和@InjectMocks注解的字段
        MockitoAnnotations.openMocks(this);
    }

    @Test
    void create_shouldThrowUsernameUnavailableException_whenUsernameIsDummy() {
        User dummyUser = new User("dummy", "password");

        // 断言create方法会抛出特定的异常
        UsernameUnavailableException exception = assertThrows(UsernameUnavailableException.class, () -> {
            userService.create(dummyUser);
        });

        // 验证异常消息
        assertEquals("Username = 'dummy is cannot be used!", exception.getMessage());

        // 验证userRepository的任何方法都没有被调用
        // 这间接证明了checkUsername在抛出异常前没有与userRepository交互
        verifyNoInteractions(userRepository);
    }

    @Test
    void create_shouldThrowUsernameIsInUseException_whenUsernameExists() {
        User existingUser = new User("existingUser", "password");
        // 模拟当existsByUsername被调用时返回true，表示用户名已存在
        when(userRepository.existsByUsername("existingUser")).thenReturn(true);

        // 断言create方法会抛出特定的异常
        UsernameIsInUseException exception = assertThrows(UsernameIsInUseException.class, () -> {
            userService.create(existingUser);
        });

        // 验证异常消息
        assertEquals(String.format("Username ='s%s' is being used by another user!", existingUser.getUsername()), exception.getMessage());

        // 验证userRepository.existsByUsername方法被调用了一次
        verify(userRepository, times(1)).existsByUsername("existingUser");
        // 验证userRepository.save方法从未被调用
        verify(userRepository, never()).save(any(User.class));
    }

    @Test
    void create_shouldSaveUserSuccessfully_whenUsernameIsAvailable() {
        User newUser = new User("newUser", "password");
        User savedUser = new User("newUser", "password", 1L); // 模拟保存后的用户

        // 模拟当existsByUsername被调用时返回false，表示用户名可用
        when(userRepository.existsByUsername("newUser")).thenReturn(false);
        // 模拟当save方法被调用时返回一个已保存的用户对象
        when(userRepository.save(any(User.class))).thenReturn(savedUser);

        // 调用create方法
        User result = userService.create(newUser);

        // 断言结果不为空，且与预期保存的用户匹配
        assertNotNull(result);
        assertEquals(savedUser.getUsername(), result.getUsername());
        assertEquals(savedUser.getId(), result.getId());

        // 验证userRepository.existsByUsername方法被调用了一次
        verify(userRepository, times(1)).existsByUsername("newUser");
        // 验证userRepository.save方法被调用了一次，且参数是任何User对象
        verify(userRepository, times(1)).save(any(User.class));
    }
}

2.5 断言与行为验证

在上述示例中，我们使用了JUnit 5的断言和Mockito的验证功能：

• assertThrows(Exception.class, () -> ...)：用于验证方法是否抛出了预期的异常。
• assertEquals(expected, actual)：用于验证异常消息或返回结果的正确性。
• verifyNoInteractions(mock)：验证mock对象没有任何方法被调用。
• verify(mock, times(n)).method()：验证mock对象的特定方法被调用了n次。
• verify(mock, never()).method()：验证mock对象的特定方法从未被调用。
• when(mock.method()).thenReturn(value)：模拟mock对象方法的返回值。

通过这些手段，我们成功地在不直接访问私有方法的情况下，验证了create方法（及其内部checkUsername私有方法）的所有行为分支。

3. 何时考虑代码重构？

如果一个私有方法无法通过任何公共方法间接测试，这通常表明代码设计存在问题，可能属于以下情况：

1. 死代码：该私有方法从未被任何公共方法调用，因此它是无用的代码。
2. 设计不佳：类的职责过于庞大，私有方法实际上应该是一个独立的公共方法或属于另一个协作类。此时应考虑重构，将该私有逻辑提取为一个独立的组件或将其提升为公共方法（如果从设计角度合理）。
3. 可见性错误：该方法最初被错误地声明为私有，实际上它是一个有用的公共接口，可以被其他组件直接调用。

4. 不推荐的做法：通过反射测试私有方法

尽管可以通过Java的反射机制来访问并调用私有方法，但这种做法强烈不推荐用于单元测试。

• 破坏封装性：反射直接绕过了访问修饰符，违背了面向对象的核心原则——封装。
• 测试脆弱：当私有方法签名（名称、参数、返回类型）发生变化时，基于反射的测试会立即失效，导致测试与实现紧密耦合，增加了维护成本。
• 可读性差：反射代码通常比直接调用更复杂，降低了测试代码的可读性。

正如《JUnit In Action》一书所指出的：“使用反射访问私有属性和方法违背了我们作为优秀学生和严谨开发人员所学到的原则，即面向对象语言建立在三个支柱之上：封装、继承和多态。”

在极少数情况下，例如处理无法重构的遗留系统，或者为了测试框架或库的内部机制，可能会不得已使用反射。但在常规业务代码的单元测试中，应始终避免使用反射。

5. 总结

测试包含私有方法的公共方法应遵循“间接测试”的原则。通过模拟依赖项并设计全面的测试用例，我们可以验证公共方法的行为，从而确保私有方法的正确性，同时维护代码的封装性和可测试性。良好的代码设计应优先考虑可测试性，避免因设计缺陷而导致测试困难。在绝大多数情况下，直接通过反射测试私有方法是不可取的，因为它破坏了面向对象的核心原则，并引入了额外的复杂性和维护成本。

本篇关于《Java如何测试私有方法的公共方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！