Mocking Final Classes and Static Methods

Direct Answer

Modern Mockito can mock or spy final classes and final instance methods when the inline mock maker is active; Mockito 5 uses inline mocking by default. Static methods are not spied on as part of an object. Use Mockito.mockStatic(Type.class) to create a scoped MockedStatic, configure calls inside a try-with-resources block, and close it so the thread-local static behavior does not leak. Some methods and JVM types remain unsupported, and frequent static mocking can signal a hard-to-test design.

Code Example

final class PaymentGateway {
    String process(int amount) { return "real-id"; }
}

@Test
void mocksAFinalClass() {
    PaymentGateway gateway = mock(PaymentGateway.class);
    when(gateway.process(100)).thenReturn("test-id");

    assertEquals("test-id", gateway.process(100));
}

@Test
void scopesAStaticMock() {
    try (MockedStatic<ClockUtil> clock = Mockito.mockStatic(ClockUtil.class)) {
        clock.when(ClockUtil::today).thenReturn(LocalDate.of(2026, 1, 2));
        assertEquals(LocalDate.of(2026, 1, 2), ClockUtil.today());
    }
}

Common Mistakes & Pitfalls

• Adding mockito-inline automatically: Mockito 5 uses the inline mock maker by default; check the actual version and configuration first.
• Leaking a static mock: always close MockedStatic, normally with try-with-resources.
• Calling static mocking a spy: mockStatic creates a scoped static mock, not an object spy.
• Using static mocking everywhere: repeated global seams are usually clearer behind an injected collaborator.
• Ignoring limitations: native methods and some JVM-sensitive targets are not ordinary mock seams.