@InjectMock replaces existing mocks

[blazmrak]

Describe the bug
Basically what I have is class C1, which implements 2 interfaces I1 and I2. Class C2 then injects those 2 interfaces. The actual (non-test) code runs well, but in testing one of the mocks is not called.

It will probably be the simplest to understand with some pseudo code, as I have a hard time explaining the problem with words.

class C1 implements I1, I2 {...}

class C2 {
  @Inject I1
  @Inject I2

  method() {
    I1.m1()
    I2.m2()
  }
}

@QuarkusTest
class Test {
  @Inject C2
  @MockInject I1
  @MockInject I2

  @Test
  test() {
    when(I1)...
    when(I2)...

    C2.method()

    verify(I1) - NOT CALLED
    verify(I2) - CALLED
  }
}

From what I understand what happens is that the mocks replace the actual implementation, but that does not seem correct to me, because the implementation is not what I really want to mock or worry about.

Now... Does this qualify as a bug, or is it a "feature"? Is there some workaround except just creating interfaces that are the "same" as implementations (one interface per class)?

Expected behavior
Both mock get called.

Actual behavior
One mock gets called.

** To reproduce **

git clone https://github.com/blazmrak/inject-mock-issue.git
mvn clean test

Environment (please complete the following information):

• Output of uname -a or ver: 10.0.19042.804
• Output of java -version: 11.0.10
• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.12
• Build tool (ie. output of mvnw --version or gradlew --version): 3.6.3

[famod]

TBH, I'd expect the same as you do. There might be some limitation related to ArC but that's pure speculation.
Someone needs to take a closer look.

/cc @geoand @mkouba

[mkouba]

Hm, what's the CDI scope of the I1 bean implementation? AFAIK the @InjectMock and friends only work for normal scoped CDI bean (e.g. @ApplicationScoped, @RequestScoped, etc).

[famod]

As long as class C1 implements I1, I2 {...} and @MockInject I2 works, C1 seems to be a normal scoped bean. 🤔
But it certainly doesn't hurt if @blazmrak would confirm. 🙂

@blazmrak a small sample project reproducing the problem would come in handy.

[mkouba]

As long as class C1 implements I1, I2...

@famod You're right, except that there might be various CDI constructs that can change the game ;-), e.g. qualifers, @Typed, @Alternative, ...

[blazmrak]

Sorry, I didn't bother to setup a repo, as I didn't know if it is a problem at all. I will get on it and update the issue.

@mkouba The scope is @ApplicationScoped.

[blazmrak]

I have added a minimal sample. Notice if you switch the order of fields in test

@InjectMock I3
@InjectMock I2

instead of

@InjectMock I2
@InjectMock I3

there is different mock which does not get called.

[blazmrak]

@mkouba @famod The problem probably lies with MockitoMocksTracker, as it is beanInstance to mock map.

Basically what happens is that the second mock that is read gets mapped to the same bean instance. Instead of a bean instance, would it be more appropriate to map the type of field + bean instance to the mock? (I have too little experience with quarkus to actually know if there would be a problem with that approach)

[geoand]

I'll take a look sometime this week.

Thanks for the reproducer and the details

[geoand]

#15427 fixes the issue