AssertJ/Mockito "NoSuchMethodError" from a version conflict - Fix in CI

By Kaveh Alemi·Latchkey

Your tests compiled against one version of AssertJ or Mockito but a different (older) version is on the runtime test classpath. A method that exists at compile time is absent at run time, so the JVM throws NoSuchMethodError.

What this error means

A test errors with java.lang.NoSuchMethodError: org.assertj.core.api.AbstractAssert.as(...) or a Mockito/ByteBuddy method, even though it compiles. The conflict comes from a transitive pin (often a Spring Boot BOM or another testing library).

junit

java.lang.NoSuchMethodError: 'org.mockito.MockedStatic
org.mockito.Mockito.mockStatic(java.lang.Class)'
	at com.example.ServiceTest.setUp(ServiceTest.java:22)
	at java.base/jdk.internal.reflect...

Diagnose it: resolve the effective POM first

Maven merges parent POMs, profiles, and settings before it builds anything. The configuration causing your failure is frequently inherited or activated by a profile that is on locally and off in CI.

Terminal

# the fully resolved configuration Maven will actually use
mvn help:effective-pom | head -60

# which profiles are active here vs on your machine?
mvn help:active-profiles

# full error, offline-safe, no colour codes to confuse the log
mvn -B -e -X <goal> 2>&1 | tail -60

Common causes

Transitive dependency pins an older version

A managed BOM or another library forces an older AssertJ/Mockito than the API you wrote against.

Mockito and ByteBuddy out of sync

Mockito needs a compatible ByteBuddy; an old ByteBuddy on the classpath breaks newer Mockito APIs like mockStatic.

Two test libraries bundle different versions

Mixing test starters can introduce duplicate, mismatched AssertJ/Mockito jars.

How to fix it

Inspect and align the versions

Find which version actually resolves, then pin the one your tests need.

Terminal

./gradlew dependencyInsight --configuration testRuntimeClasspath \
  --dependency org.mockito:mockito-core

Force a consistent version

Pin Mockito/AssertJ (and ByteBuddy) so one version wins.

gradle

dependencies {
  testImplementation 'org.mockito:mockito-core:5.12.0'
  testImplementation 'org.assertj:assertj-core:3.26.0'
  constraints { testImplementation 'net.bytebuddy:byte-buddy:1.14.18' }
}

Override the BOM-managed version (Maven)

Declare the test library version explicitly to override a BOM pin.

pom.xml

<properties>
  <mockito.version>5.12.0</mockito.version>
</properties>

How to prevent it

Let one BOM manage test-library versions and do not mix conflicting starters.
Keep Mockito and ByteBuddy on compatible versions.
Run dependencyInsight/dependency:tree when a NoSuchMethodError appears.

Frequently asked questions

What causes AssertJ/Mockito "NoSuchMethodError" from a version conflict?

There are 3 common causes: transitive dependency pins an older version, mockito and bytebuddy out of sync, and two test libraries bundle different versions. A managed BOM or another library forces an older AssertJ/Mockito than the API you wrote against.

How do I fix AssertJ/Mockito "NoSuchMethodError" from a version conflict?

There are 3 fixes depending on which cause you have: inspect and align the versions, force a consistent version, and override the bom-managed version (maven). Work through them in order, since the first is the most common.

What does AssertJ/Mockito "NoSuchMethodError" from a version conflict actually mean?

A test errors with java.lang.NoSuchMethodError: org.assertj.core.api.AbstractAssert.as(...) or a Mockito/ByteBuddy method, even though it compiles.

How do I stop AssertJ/Mockito "NoSuchMethodError" from a version conflict happening again?

Let one BOM manage test-library versions and do not mix conflicting starters. The prevention section lists 3 changes that keep it from recurring.