Cannot mock/spy class error, after adding quarkus-junit5-mockito dependency

[ennishol]

Describe the bug

After adding quarkus-junit5-mockito dependency, tests start to fail with Cannot mock/spy class error

Expected behavior

Test should work

Actual behavior

Tests fail

How to Reproduce?

con-testing.tar.gz

1. Run ./mvnw quarkus:dev and press r to start testing
2. Tests are failing
3. When quarkus-junit5-mockito is removed with the test using @InjectMock, the failing tests become green

Output of uname -a or ver

No response

Output of java -version

openjdk version "21.0.1" 2023-10-17 LTS Corretto-21.0.1.12.1 (build 21.0.1+12-LTS)

Quarkus version or git rev

5.6.4

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.6

Additional information

No response

[quarkus-bot]

/cc @geoand (testing)

[famod]

The problem is that Quarkus 3.x is fixating the old subclass mockmaker, which cannot mock e.g. record (like you do in your example).
There is a hint and a workaround (!) in the 3.0 migration guide: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.0#fixation-of-the-mockito-subclass-mockmaker

FTR, this also happens with Java 17.

@geoand are you planning on supporting the default inline mockmaker properly? I fear that the issue of Quarkus relying on the old and inferior mockmaker will only become worse.
Until then I think the testing guide should contain a similar hint as the 3.0 migration guide (see above).

[ennishol]

@famod but then I will run again in the memory usage problem, right? #31251
I'll give it a try

[ennishol]

@famod unfortunately exclusion of mockito-subclass leads to OOM in integration tests, But at least for unit tests I can use it as a workaround

[geoand]

Right, we'll have to tackle the memory leak at some point and support inline properly.

[famod]

FWIW, I was just hit by subclass mock maker limitations when trying to @InjectSpy a spring-data-jpa JpaRepository that has a default method - error from mockito: "Cannot call abstract real method on java object!"

So +1 (again) to move on to inline.

[gsmet]

Could we install a callback somewhere to clean the mocks after test execution?

[gian1200]

Until then I think the testing guide should contain a similar hint as the 3.0 migration guide (see above).

+1 to the addition in the Testing Guide.

Although googling the error can lead you to #32952 (comment) (or the migration guide), new users aren't expected to read Migration guides when creating apps directly on Quarkus 3, right? 🤔

[geoand]

I opened #46119 to fix this, however I could not find a way to reproduce the original issue with OOM error so I don't know if the change reintroduces it or not...

[gsmet]

Should we make sure we call Mockito.framework().clearInlineMocks(); after each test as was mentioned in one of the issues?

Not sure if it's still needed though. I think we should probably bite the bullet and adjust if we have reports. A lot of things changed since 3.0.0.

[geoand]

Should we make sure we call Mockito.framework().clearInlineMocks(); after each test as was mentioned in one of the issues?

That's essentially what the PR does.

I think we should probably bite the bullet and adjust if we have reports. A lot of things changed since 3.0.0.

Right. I'm like +0.5 on that. I still wish I could have reproduced the original issue though...

[gsmet]

That's essentially what #46119 does.

Ah yes sorry. Not my best self right now.

[geoand]

No worries :)