Следует ли использовать @Autowired и @SpringBootTest в модульных тестах?

Question

В проекте, где я работаю, мы инициализировали Сервисы для модульного тестирования следующим образом:

1. Макетные зависимости, необходимые для Сервиса.
2. Создание Сервисаиспользуя конструктор.

Примерно так:

@RunWith(SpringRunner.class)
public class ServiceTest extends AbstractUnitTest {

  @Mock private Repository repository;
  private Service service;

  @Before
  public void init() {
    service = new Service(repository);
    when(repository.findById(any(Long.class))).thenReturn(Optional.of(new Entity()));
  }
}

Но наш новый разработчик предложил использовать @Autowired и @SpringBootTest

@SpringBootTest(classes = ServiceTest.class)
@MockBean(classes = Repository.class)
@RunWith(SpringRunner.class)
public class ServiceTest extends AbstractUnitTest {

  @MockBean private Repository repository;
  @Autowired private Service service;

  @Before
  public void init() {
    when(repository.findById(any(Long.class))).thenReturn(Optional.of(new Entity()));
  }
}

До этого я предполагал, что @Autowired и @SpringBootTest должны использоваться только в интеграционных тестах. Но много гуглил, и я вижу, что некоторые люди используют эти два в модульных тестах. Я прочитал boot-features-testing . Кроме того, я прочитал это Модульные тесты против интеграционных тестов с Spring . Для меня все еще не очень хорошо, что нам нужно задействовать Spring для внедрения зависимостей для модульных тестов, так как мы можем сделать это сами для выполнения модульного тестирования. Так следует ли использовать @Autowired и @SpringBootTest в модульных тестах?

Answer 1

Нет. Тест unit предназначен для проверки отдельного компонента в изоляции. Использование инжектора в ваши bean-компоненты позволяет очень просто вызывать new SomeService(myMock), Spring не требуется.

Запись компонент или функциональных тестов (тестирование вашего приложения, но не проводки)это до внешних сервисов для полного интеграционного теста, имитирующего только внешние интерфейсы (это хорошо для таких вещей, как тесты MockMvc), хорошо подходит для @SpringBootTest, и в этом случае вам может понадобиться создать фиктивные объекты в конфигурации Spring ивключите их в свой тест, чтобы вы могли ими манипулировать.

Answer 2

В тестах TDD должны быть полезными, прямолинейными, быстрыми и держать обслуживание на минимальном уровне. В противном случае разработчики будут раздражены и постараются избежать тестов.
Поэтому я рекомендую не быть строгим, если это чистый юнит-тест или немного интеграции. Выберите область тестирования, которая лучше всего подходит для вашей ситуации, и используйте технические функции, которые подходят для этой области.

Не используйте DI, если вы проводите «настоящий» юнит-тест, тестируя автономный метод насвой. Эти тесты имеют смысл, если метод делает что-то значимое, например, алгоритм, расчет, принятие решения. Поддельные источники данных - это отличный способ получить предсказуемые входные значения. Недостатком @SpringBootTest, который вам на самом деле не нужен, является адское время запуска (зависит от размера проекта), которое действительно раздражает.

Используйте CDI, если метод вызывает функциональность зависимости. 1) Установка myService.service2 = new Service2() вручную оставляет вам Service2, который также не обрабатывается DI-контейнером, который может потребовать от вас установить еще несколько зависимостей ... 2) CDI в тестировании - это бриз с Spring - так зачем вамРаздувать ваши тесты с установочным кодом? 3) DI включает прокси, которые иногда ведут себя немного иначе, чем простые экземпляры.

Используйте @ContextConfiguration(classes = {ServiceTest.class}) для получения CDI с более быстрым запуском по сравнению с @ SpringBootTest.

Не тестируйте склеивание кода сЮниттесты, поскольку они не имеют внутренней ценности. Эти тесты трудны для понимания (кто любит документировать тесты), потребуют много насмешек и часто будут подвергаться изменениям. Протестируйте такой код в сочетании с другими методами / классами, даже если это означает, что у вас есть только интеграционные тесты для этих частей кода.