ChatGPT解决这个技术问题 Extra ChatGPT

Initialising mock objects - MockIto

There are many ways to initialize a mock object using MockIto. What is best way among these ?

1.

 public class SampleBaseTestCase {

   @Before public void initMocks() {
       MockitoAnnotations.initMocks(this);
   }

@RunWith(MockitoJUnitRunner.class)

mock(XXX.class);

suggest me if there are any other ways better than these...


S
Skillz

For the mocks initialization, using the runner or the MockitoAnnotations.initMocks are strictly equivalent solutions. From the javadoc of the MockitoJUnitRunner :

JUnit 4.5 runner initializes mocks annotated with Mock, so that explicit usage of MockitoAnnotations.initMocks(Object) is not necessary. Mocks are initialized before each test method.

The first solution (with the MockitoAnnotations.initMocks) could be used when you have already configured a specific runner (SpringJUnit4ClassRunner for example) on your test case.

The second solution (with the MockitoJUnitRunner) is the more classic and my favorite. The code is simpler. Using a runner provides the great advantage of automatic validation of framework usage (described by @David Wallace in this answer).

Both solutions allows to share the mocks (and spies) between the test methods. Coupled with the @InjectMocks, they allow to write unit tests very quickly. The boilerplate mocking code is reduced, the tests are easier to read. For example:

@RunWith(MockitoJUnitRunner.class)
public class ArticleManagerTest {

    @Mock private ArticleCalculator calculator;
    @Mock(name = "database") private ArticleDatabase dbMock;
    @Spy private UserProvider userProvider = new ConsumerUserProvider();

    @InjectMocks private ArticleManager manager;

    @Test public void shouldDoSomething() {
        manager.initiateArticle();
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        manager.finishArticle();
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Pros: The code is minimal

Cons: Black magic. IMO it is mainly due to the @InjectMocks annotation. With this annotation "you loose the pain of code" (see the great comments of @Brice)

The third solution is to create your mock on each test method. It allow as explained by @mlk in its answer to have "self contained test".

public class ArticleManagerTest {

    @Test public void shouldDoSomething() {
        // given
        ArticleCalculator calculator = mock(ArticleCalculator.class);
        ArticleDatabase database = mock(ArticleDatabase.class);
        UserProvider userProvider = spy(new ConsumerUserProvider());
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.initiateArticle();

        // then 
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        // given
        ArticleCalculator calculator = mock(ArticleCalculator.class);
        ArticleDatabase database = mock(ArticleDatabase.class);
        UserProvider userProvider = spy(new ConsumerUserProvider());
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.finishArticle();

        // then
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Pros: You clearly demonstrate how your api works (BDD...)

Cons: there is more boilerplate code. (The mocks creation)

My recommandation is a compromise. Use the @Mock annotation with the @RunWith(MockitoJUnitRunner.class), but do not use the @InjectMocks :

@RunWith(MockitoJUnitRunner.class)
public class ArticleManagerTest {

    @Mock private ArticleCalculator calculator;
    @Mock private ArticleDatabase database;
    @Spy private UserProvider userProvider = new ConsumerUserProvider();

    @Test public void shouldDoSomething() {
        // given
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.initiateArticle();

        // then 
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        // given
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.finishArticle();

        // then 
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Pros: You clearly demonstrate how your api works (How my ArticleManager is instantiated). No boilerplate code.

Cons: The test is not self contained, less pain of code


Be careful though, the annotations are useful but they don't protect you against to craft poor OO design (or to degrade it). Personally while I'm happy to reduce boilerplate code, I loose the pain of code (or PITA) that is the trigger to change the design to a better one, so I and the team are paying attention to OO design. I feel that following OO design with principles like SOLID design or the GOOS ideas is much more important that choosing how to instantiate mocks.
(follow up) If you don't see how this object is created you don't feel the pain about it, and future programmers might not react well if new functionality should be added. Anyway that is arguable both ways, I'm just saying to be careful about it.
It is NOT CORRECT that these two are equivalent. It is NOT TRUE that simpler code is the only advantage to using MockitoJUnitRunner. For more information about the differences, see the question at stackoverflow.com/questions/10806345/… and my answer to it.
@Gontard Yeah sure dependencies are visible, but I've seen code gone wrong using this approach. About using the Collaborator collab = mock(Collaborator.class), in my opinion this way is certainly a valid approach. While this might tend to be verbose, you can gain in understandability and refactorability of the tests. Both ways have their pros and cons, I've not yet decided which approach is better. Amyway it's always possible to write crap, and probably depends on the context and the coder.
@mlk i am totally agree with you. My english is not very good and it lacks nuances. My point was to insist on the UNIT word.
C
Community

There is now (as of v1.10.7) a fourth way to instantiate mocks, which is using a JUnit4 rule called MockitoRule.

@RunWith(JUnit4.class)   // or a different runner of your choice
public class YourTest
  @Rule public MockitoRule rule = MockitoJUnit.rule();
  @Mock public YourMock yourMock;

  @Test public void yourTestMethod() { /* ... */ }
}

JUnit looks for subclasses of TestRule annotated with @Rule, and uses them to wrap the test Statements that the Runner provides. The upshot of this is that you can extract @Before methods, @After methods, and even try...catch wrappers into rules. You can even interact with these from within your test, the way that ExpectedException does.

MockitoRule behaves almost exactly like MockitoJUnitRunner, except that you can use any other runner, such as Parameterized (which allows your test constructors to take arguments so your tests can be run multiple times), or Robolectric's test runner (so its classloader can provide Java replacements for Android native classes). This makes it strictly more flexible to use in recent JUnit and Mockito versions.

In summary:

Mockito.mock(): Direct invocation with no annotation support or usage validation.

MockitoAnnotations.initMocks(this): Annotation support, no usage validation.

MockitoJUnitRunner: Annotation support and usage validation, but you must use that runner.

MockitoRule: Annotation support and usage validation with any JUnit runner.

See also: How JUnit @Rule works?


In Kotlin, the rule looks like this: @get:Rule val mockitoRule: MockitoRule = MockitoJUnit.rule()
f
fl0w

A little example for JUnit 5 Jupiter, the "RunWith" was removed you now need to use the Extensions using the "@ExtendWith" Annotation.

@ExtendWith(MockitoExtension.class)
class FooTest {

  @InjectMocks
  ClassUnderTest test = new ClassUnderTest();

  @Spy
  SomeInject bla = new SomeInject();
}

T
Thanthu

1. Using MockitoAnnotations.openMocks():

The MockitoAnnotations.initMock() method in Mockito 2 is deprecated and replaced with MockitoAnnotations.openMocks() in Mockito 3. The MockitoAnnotations.openMocks() method returns an instance of AutoClosable which can be used to close the resource after the test. Below is an example using MockitoAnnotations.openMocks().

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;


class MyTestClass {

    AutoCloseable openMocks;

    @BeforeEach
    void setUp() {
        openMocks = MockitoAnnotations.openMocks(this);
        // my setup code...
    }

    @Test
    void myTest() {
        // my test code...
        
    }

    @AfterEach
    void tearDown() throws Exception {
        // my tear down code...
        openMocks.close();
    }

}

2. Using @ExtendWith(MockitoExtension.class):

As of JUnit5 @RunWith has been removed. Below is an example using @ExtendWith:

@ExtendWith(MockitoExtension.class)
class MyTestClass {

    @BeforeEach
    void setUp() {
        // my setup code...
    }

    @Test
    void myTest() {
        // my test code...

    }

    @AfterEach
    void tearDown() throws Exception {
        // my tear down code...
    }

}

I am converting code that uses JUnit4 and Mockito 2 to Jupiter and Mockito 3. Thank you for this up-to-date answer! Updating MockitoAnnotations.initMocks(this); to example 1 worked great. Most of the other answers are now obsolete.
Actually it has been deprecated in Mockito 3.4.0, not in Mockito 3. You won't find openMocks method in Mockito 3.3.0
M
Michael Lloyd Lee mlk

MockitoAnnotations & the runner have been well discussed above, so I'm going to throw in my tuppence for the unloved:

XXX mockedXxx = mock(XXX.class);

I use this because I find it a little bit more descriptive and I prefer (not out right ban) unit tests not to use member variables as I like my tests to be (as much as they can be) self contained.


Is there any other advantage over using mock(XX.class) except making the test case to be self contained ?
Less magic to have to understand in order to read the test. You declare the variable, and give it a value - no annotations, reflection etc.
e
emd

There is a neat way of doing this.

If it's an Unit Test you can do this: @RunWith(MockitoJUnitRunner.class) public class MyUnitTest { @Mock private MyFirstMock myFirstMock; @Mock private MySecondMock mySecondMock; @Spy private MySpiedClass mySpiedClass = new MySpiedClass(); // It's gonna inject the 2 mocks and the spied object per reflection to this object // The java doc of @InjectMocks explains it really well how and when it does the injection @InjectMocks private MyClassToTest myClassToTest; @Test public void testSomething() { } }

EDIT: If it's an Integration test you can do this(not intended to be used that way with Spring. Just showcase that you can initialize mocks with diferent Runners): @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration("aplicationContext.xml") public class MyIntegrationTest { @Mock private MyFirstMock myFirstMock; @Mock private MySecondMock mySecondMock; @Spy private MySpiedClass mySpiedClass = new MySpiedClass(); // It's gonna inject the 2 mocks and the spied object per reflection to this object // The java doc of @InjectMocks explains it really well how and when it does the injection @InjectMocks private MyClassToTest myClassToTest; @Before public void setUp() throws Exception { MockitoAnnotations.initMocks(this); } @Test public void testSomething() { } }


If MOCK is involved in Integration tests also, will it makes sense ?
actually it won't, your right. I just wanted to show to possibilities of Mockito. For instance if your use RESTFuse you have to user their runner so you can initialize mocks with MockitoAnnotations.initMocks(this);
S
Slawomir Jaranowski

In te lastest version of Mockito the method MockitoAnnotations.initMocks is deprecated

Preferred way is use

MockitoJUnitRunner or MockitoRule for JUnit4

MockitoExtension for JUnit5

MockitoTestNGListener for TestNG

If you can not use dedicated runner/extension you can use MockitoSession


n
neXus

The other answers are great and contain more detail if you want/need them. In addition to those, I would like to add a TL;DR:

Prefer to use @RunWith(MockitoJUnitRunner.class) If you cannot (because you already use a different runner), prefer to use @Rule public MockitoRule rule = MockitoJUnit.rule(); Similar to (2), but you should not use this anymore: @Before public void initMocks() { MockitoAnnotations.initMocks(this); } If you want to use a mock in just one of the tests and don't want to expose it to other tests in the same test class, use X x = mock(X.class)

(1) and (2) and (3) are mutually exclusive. (4) can be used in combination with the others.