Introduction

This NoSuchMethodError almost always means your test code was compiled against one Mockito API version but is running with a different Mockito JAR at runtime. The missing method is a strong sign of dependency mismatch, not a normal mocking mistake in the test itself.

What NoSuchMethodError Means

NoSuchMethodError is a binary compatibility failure. The code that is running expects a method signature to exist in a class, but the actual class loaded at runtime does not have that method.

In this case, something in your test stack expects:

org.mockito.MockingDetails.getMockCreationSettings()

but the Mockito version actually on the runtime classpath does not provide that exact method signature.

That usually happens because:

• different modules pull in different Mockito versions
• another library brings an older transitive dependency
• the IDE and the build tool are resolving dependencies differently

Check the Dependency Tree First

The fastest way to confirm the problem is to inspect the resolved dependency graph.

For Maven:

mvn dependency:tree

For Gradle:

./gradlew dependencies

Look for multiple Mockito artifacts or conflicting versions such as:

• 'mockito-core'
• 'mockito-junit-jupiter'
• 'mockito-inline'

Those pieces should be aligned. If one is older or pulled transitively by another test library, you can get exactly this kind of method mismatch.

Force a Consistent Mockito Version

In Maven, declare the Mockito version explicitly so the build does not drift across transitive dependencies:

1<properties>
2  <mockito.version>5.11.0</mockito.version>
3</properties>
4
5<dependencies>
6  <dependency>
7    <groupId>org.mockito</groupId>
8    <artifactId>mockito-core</artifactId>
9    <version>${mockito.version}</version>
10    <scope>test</scope>
11  </dependency>
12</dependencies>

In Gradle:

dependencies {
    testImplementation("org.mockito:mockito-core:5.11.0")
}

The exact version is less important than consistency. The main fix is to stop mixing incompatible Mockito releases in the same test runtime.

Watch for Extension and Runner Mismatches

Mockito errors like this often appear indirectly through other test integrations. For example:

• JUnit extensions compiled against a different Mockito API
• Spring test helpers bringing in an older version
• IDE test runners caching stale dependencies

That is why simply changing one line in build.gradle or pom.xml is not always enough. After aligning versions, do a clean rebuild so old class files and cached libraries do not keep contaminating the test run.

./gradlew clean test

or:

mvn clean test

Do Not Ignore the Runtime Classpath

A project can compile successfully and still fail at runtime if one classpath is used for compilation and another for execution. IDEs sometimes hide this problem because they may use cached or partially refreshed dependency state.

If command-line builds succeed but the IDE fails, reimport the project and invalidate old caches. If the IDE succeeds but CI fails, inspect the CI dependency resolution and compare it with the local build output.

Keep Test Libraries Aligned as a Set

Mockito issues like this rarely live in isolation. If your project also uses JUnit integrations, Spring test libraries, or custom test starters, align the whole test stack deliberately instead of upgrading one artifact at random and hoping the classpath sorts itself out.

Common Pitfalls

• Looking for a bug in the test code when the real problem is a dependency mismatch.
• Mixing mockito-core, mockito-inline, or framework integrations at different versions.
• Fixing one module's Mockito version while another module still brings an incompatible transitive version.
• Trusting IDE resolution without comparing it to the actual build-tool dependency graph.
• Forgetting to clean and rebuild after changing the dependency version.

Summary

• This NoSuchMethodError is usually caused by Mockito version mismatch at runtime.
• Check the dependency tree first and look for multiple Mockito versions.
• Align Mockito-related artifacts so they all use one compatible version.
• Clean and rebuild after fixing dependencies so stale classpath state does not persist.
• Treat this as a binary compatibility problem, not as a normal mocking API usage problem.