mock(Class<T> classToMock, String name) name was ignored

i have run the test named “InjectionOfInlinedMockDeclarationIssueTest” and try to modfied the name of the mock failed with testing , by it always passed test

@RunWith(MockitoJUnitRunner.class)
public class InjectionOfInlinedMockDeclarationIssueTest {

    @InjectMocks private Receiver receiver;
    @InjectMocks private Receiver spiedReceiver;

    private Antenna oldAntenna         = mock(Antenna.class);
    private Antenna satelliteAntenna = mock(Antenna.class);
    
   /*opt1*/
    private Antenna antenna               = mock(Antenna.class,"dvbtAntenna");
   /*opt2*/
    private Antenna antenna               = mock(Antenna.class,"testing");
   /*opt3*/
    private Antenna antenna               = mock(Antenna.class);

    @Test
    public void named_mocks_should_be_resolved_with_their_name() throws Exception {
        //should not same
        assertSame(antenna    , receiver.dvbtAntenna);
        assertNotSame(antenna , oldAntenna);

        assertNotSame(receiver         , spiedReceiver);
        assertNotSame(oldAntenna       , satelliteAntenna);
        assertNotSame(oldAntenna       , antenna);
        assertNotSame(satelliteAntenna , antenna);
    }

    // note that static class is not private !!
    static class Receiver {
        Antenna oldAntenna;
        Antenna satelliteAntenna;
        Antenna dvbtAntenna;
    }
    private static class Antenna { }
}

leave the opt1 or opt2 or opt3 alone , the test was always passed .

plz fix this bug

[TimvdLippe]

@SeriyBg I think this is working as intended, but maybe one of the other @mockito/core can chime in as well.

If you would like to help us out, we are eagerly looking for contributions! Check out this list of issues to find an easy one to start (or participate in the discussion): https://github.com/mockito/mockito/issues?q=is%3Aissue+is%3Aopen+label%3A"please+contribute"

[raphw]

Sorry this took so long. As a matter of fact, I would suggest that Mockito should throw an exception if mocks of the same type are in conflict to one another. This is always better then undefined behavior.

We could also add a boolean property to @InjectMocks that allows to fall back to the old behavior but in this case, I would actually suggest to just throw the exception as this behavior might just break by an implementation detail in the future anyways.