Mastering Java Unit Testing: A Deep Dive into Mockito & PowerMock

Introduction

Inspired by a Qing dynasty saying that emphasizes deep mastery, the author shares a personal journey of achieving 100% line coverage for a Java project using unit testing.

Test Framework Overview

Mockito is a lightweight mocking framework that isolates the class under test from its dependencies. PowerMock extends Mockito to mock static, final, private, and constructor methods, but its use can affect JaCoCo coverage.

Adding Dependencies

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-core</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-mockito2</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>

The powermock.version can be adjusted as needed; PowerMock already bundles Mockito and JUnit.

Typical Service Code Example

/**
 * User service class
 */
@Service
public class UserService {
    /** User DAO */
    @Autowired
    private UserDAO userDAO;
    /** ID generator */
    @Autowired
    private IdGenerator idGenerator;
    @Value("${userService.canModify}")
    private Boolean canModify;

    /** Create user */
    public Long createUser(UserVO userCreate) {
        Long userId = userDAO.getIdByName(userCreate.getName());
        if (Objects.isNull(userId)) {
            userId = idGenerator.next();
            UserDO create = new UserDO();
            create.setId(userId);
            create.setName(userCreate.getName());
            userDAO.create(create);
        } else if (Boolean.TRUE.equals(canModify)) {
            UserDO modify = new UserDO();
            modify.setId(userId);
            modify.setName(userCreate.getName());
            userDAO.modify(modify);
        } else {
            throw new UnsupportedOperationException("不支持修改");
        }
        return userId;
    }
}

Writing Unit Test Cases

The process is divided into four main phases:

Define the object under test.

Mock dependent objects (fields, parameters, return values).

Inject mocked dependencies into the object.

Execute the method and verify behavior.

1. Define the Object Under Test

Either instantiate directly, use Mockito.spy, or annotate with @InjectMocks:

@InjectMocks
private UserService userService;

2. Mock Dependent Objects

@Mock
private UserDAO userDAO;
@Mock
private IdGenerator idGenerator;

3. Inject Dependencies

Injection can be done via setters, ReflectionTestUtils.setField, Whitebox.setInternalState, or @InjectMocks.

4. Simulate Method Calls

Use Mockito.doReturn(...).when(...) or Mockito.when(...).thenReturn(...) to stub methods, including handling of any arguments with matchers like anyString(), any(), nullable(), or isNull(). For static, final, private, or constructor methods, employ PowerMock’s PowerMockito utilities.

Verification Techniques

Mockito provides a rich set of verification APIs: verify(mock).method(args) – default once. verify(mock, never()).method(args) – never called. verify(mock, times(n)).method(args) – exactly n times. verifyNoMoreInteractions(mock) – no other calls. ArgumentCaptor – capture arguments for deeper assertions.

PowerMockito’s verifyPrivate, verifyNew, and verifyStatic for special cases.

Exception Validation

JUnit 5’s assertThrows or JUnit 4’s @Test(expected=...) and ExpectedException rule can be used to assert exception type, message, and cause.

Common Issues and Solutions

Several practical problems are discussed with concrete fixes:

PowerMock’s impact on JaCoCo coverage – avoid mocking static/final methods when coverage is required.

ArgumentCaptor capturing mutable lists – capture a copy or store values inside the stub.

Mocking Lombok’s @Slf4j static logger – use a helper to set the static final field.

Class‑loader conflicts with Pandora container – switch to PandoraBootRunner and initialize mocks manually.

Suppressing unchecked warnings – use @Mock/@Captor, temporary subclasses, CastUtils.cast, or generic helper methods.

Conclusion

By following the outlined workflow—choosing Mockito as the primary tool, resorting to PowerMock only when necessary, and applying the verification and exception‑handling patterns presented—developers can write clear, maintainable unit tests that achieve high coverage without sacrificing readability.