MockitoSession vs MockitoJUnitRunner

Direct Answer

MockitoSession gives explicit programmatic lifecycle control: build it with Mockito.mockitoSession(), call startMocking(), and always call finishMocking() so strictness validation and cleanup run. MockitoJUnitRunner integrates Mockito with JUnit 4 and owns that lifecycle for a test class. In JUnit Jupiter, @ExtendWith(MockitoExtension.class) is the normal choice. A session is useful for a custom framework or lifecycle, not because its methods are openSession and closeSession—those methods do not exist.

Code Example

// Manual MockitoSession (framework-agnostic)
class ManualMockitoTest {
    private MockitoSession mockitoSession;
    private PaymentGateway gateway;

    void setup() {
        mockitoSession = Mockito.mockitoSession()
            .initMocks(this)  // initializes @Mock fields
            .strictness(Strictness.STRICT_STUBS)
            .startMocking();
        gateway = mock(PaymentGateway.class);  // or use @Mock field
    }

    void teardown() {
        mockitoSession.finishMocking();  // validates stubs, cleans up
    }
}

// JUnit 4 with MockitoJUnitRunner (deprecated for new projects)
@RunWith(MockitoJUnitRunner.class)  // JUnit 4 only
class JUnit4MockitoTest {
    @Mock
    private PaymentGateway gateway;  // runner initializes this
}

// JUnit 5 with MockitoExtension (modern approach)
@ExtendWith(MockitoExtension.class)  // JUnit 5
class JUnit5MockitoTest {
    @Mock
    private PaymentGateway gateway;  // extension initializes this
}

Common Mistakes & Pitfalls

• Using MockitoJUnitRunner in JUnit 5: Trying to use @RunWith(MockitoJUnitRunner.class) in a JUnit 5 test class—JUnit 5 doesn't support runners, causing a runtime error that MockitoJUnitRunner is not found or ignored.
• Forgetting to close MockitoSession: Opening a session with startMocking() but never calling finishMocking(), which leaks resources and prevents strict stubbing validation from running.
• Mixing initialization styles: Using @ExtendWith(MockitoExtension.class) and also manually creating a MockitoSession in @BeforeEach—you initialize mocks twice, which can cause subtle issues and is completely redundant.