Инициализация фиктивных объектов - MockIto

Есть много способов инициализировать фиктивный объект с помощью MockIto. Какой из них лучший?

1.

 public class SampleBaseTestCase {

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

2.

@RunWith(MockitoJUnitRunner.class)

[РЕДАКТИРОВАТЬ] 3.

mock(XXX.class);

предложите мне, есть ли другие способы лучше, чем эти ...

Для инициализации mocks использование runner или the MockitoAnnotations.initMocks- строго эквивалентные решения. Из javadoc 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.

Первое решение (с MockitoAnnotations.initMocks) можно использовать, когда вы уже настроили конкретный бегун ( SpringJUnit4ClassRunnerнапример) для своего тестового примера.

Второе решение (с MockitoJUnitRunner) более классическое и мое любимое. Код проще. Использование бегуна дает большое преимущество автоматической проверки использования фреймворка (описанного в этом ответе @David Wallace ).

Оба решения позволяют разделять моки (и шпионы) между методами тестирования. Вкупе с ними @InjectMocksони позволяют очень быстро писать модульные тесты. Уменьшен шаблонный макет кода, тесты легче читать. Например:

@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));
    }
}

Плюсы: Код минимальный

Минусы: Черная магия. ИМО, это в основном из-за аннотации @InjectMocks. С этой аннотацией «вы теряете боль кода» (см. Замечательные комментарии @Brice )

Третье решение - создать свой макет для каждого метода тестирования. Это позволяет, как объяснил @mlk в своем ответе, иметь " автономный тест ".

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));
    }
}

Плюсы: вы четко демонстрируете, как работает ваш api (BDD ...)

Минусы: больше шаблонного кода. (Создание макетов)

Моя рекомендация - это компромисс. Используйте @Mockаннотацию с @RunWith(MockitoJUnitRunner.class), но не используйте @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));
    }
}

Плюсы: вы четко демонстрируете, как работает ваш api (как ArticleManagerсоздается экземпляр my ). Нет шаблонного кода.

Минусы: тест не самодостаточен, меньше проблем с кодом.

Теперь (начиная с версии 1.10.7) существует четвертый способ создания моков, который использует правило JUnit4 под названием 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 ищет подклассы TestRule, аннотированные @Rule , и использует их для обертывания тестовых выражений , которые предоставляет Runner . В результате вы можете извлекать методы @Before, методы @After и даже пытаться ... перехватывать обертки в правила. Вы даже можете взаимодействовать с ними из своего теста, как это делает ExpectedException .

MockitoRule ведет себя почти так же, как MockitoJUnitRunner , за исключением того, что вы можете использовать любой другой бегун, например Parameterized (который позволяет вашим конструкторам тестов принимать аргументы, чтобы ваши тесты можно было запускать несколько раз), или средство запуска тестов Robolectric (так что его загрузчик классов может предоставлять замену Java. для собственных классов Android). Это делает его более гибким в использовании в последних версиях JUnit и Mockito.

В итоге:

• Mockito.mock(): Прямой вызов без поддержки аннотаций или проверки использования.
• MockitoAnnotations.initMocks(this): Поддержка аннотаций, без проверки использования.
• MockitoJUnitRunner: Поддержка аннотаций и проверка использования, но вы должны использовать этот бегун.
• MockitoRule: Поддержка аннотаций и проверка использования с любым исполнителем JUnit.

См. Также: Как работает JUnit @Rule?

Есть отличный способ сделать это.

• Если это модульный тест, вы можете сделать это:

  @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() {
      }
  }
  

• РЕДАКТИРОВАТЬ: если это тест интеграции, вы можете сделать это (не предназначено для использования таким образом с Spring. Просто продемонстрируйте, что вы можете инициализировать макеты с разными 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() {
      }
  }
  

MockitoAnnotations и раннер были хорошо обсуждены выше, поэтому я собираюсь добавить свою помощь нелюбимым:

XXX mockedXxx = mock(XXX.class);

Я использую это, потому что считаю его немного более описательным, и я предпочитаю (а не из-за правильного запрета) модульные тесты не использовать переменные-члены, поскольку мне нравится, чтобы мои тесты были (насколько это возможно) самодостаточными.

Небольшой пример для JUnit 5 Jupiter, «RunWith» был удален, теперь вам нужно использовать расширения, используя аннотацию «@ExtendWith».

@ExtendWith(MockitoExtension.class)
class FooTest {

  @InjectMocks
  ClassUnderTest test = new ClassUnderTest();

  @Spy
  SomeInject bla = new SomeInject();
}

Другие ответы великолепны и содержат более подробную информацию, если они вам нужны / нужны.
В дополнение к этому я хотел бы добавить TL; DR:

1. Предпочитаю использовать
   • @RunWith(MockitoJUnitRunner.class)
2. Если вы не можете (потому что вы уже используете другой бегун), предпочитайте использовать
   • @Rule public MockitoRule rule = MockitoJUnit.rule();
3. Аналогично (2), но вам больше не следует использовать это:
   • @Before public void initMocks() { MockitoAnnotations.initMocks(this); }
4. Если вы хотите использовать макет только в одном из тестов и не хотите предоставлять его другим тестам в том же тестовом классе, используйте
   • X x = mock(X.class)

(1), (2) и (3) исключают друг друга.
(4) можно использовать в сочетании с другими.