Dagger2: как использовать @Inject в тесте JUnit?
Я хотел бы иметь возможность вводить зависимости в тесты JUnit с помощью Dagger 2 (я новичок в этой структуре). Исходя из Spring, вы можете сделать что-то вроде этого:
@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest(classes = MyApplication.class)
public class MyTestClass {
@Autowired
private MyService service;
@Test
public void testMySerivce() { /* ... */ }
}
... но с Dagger 2 я еще не нашел решения, которое не полагалось бы на явный DaggerMyComponent.builder().build().myService().
В идеале я мог бы представить решение, которое выглядело бы примерно так:
// tell JUnit that dagger needs to do some post processing
@RunWith(DaggerJUnit4Runner.class)
// tell dagger which component classes to use for injection
@Components(MyComponent.class)
public class MyTestClass {
@Inject
private MyService service;
@Test
public void testMySerivce() { /* ... */ }
}
К сожалению, DaggerJunit4Runner отсутствует.
Будем очень признательны за любые подсказки о том, как это можно сделать.
Ответы 1
Я не видел ни встроенной функции для этого, ни какой-либо известной библиотеки тестирования, которая бы это поддерживала.
Dagger выполняет всю связку зависимостей во время компиляции и только так, как вы ему указываете; в отличие от Spring, здесь нет кода для чтения класса тестирования во время выполнения или предоставления необходимых ему зависимостей. Призыв Dagger к Guice и Spring исходит из компиляции, проверки и оптимизации во время компиляции. Хотя то, что вы описываете, было бы очень полезно, такое размышление противоречит первоначальным мотивам Даггера. Либо ваш компонент Dagger скомпилирован со сгенерированным кодом для внедрения теста, либо вам нужно иметь возможность извлекать эти зависимости независимо, как вы указали выше.
Для модульных тестов вам, вероятно, потребуется пропустить Dagger и создать свои классы или их макеты вручную; для системных или интеграционных тестов вам необходимо предоставить все необходимые классы в определении компонента. Если вы хотите заменить зависимости тестовыми двойниками для повторяемости или изоляции, вам необходимо сделать свой компонент достаточно настраиваемым, чтобы принять заменяющие реализации, или вам нужно будет создать новую реализацию компонента для тестирования, которая вместо этого использует тестовые двойники. реальных реализаций.
@ Alan47 Это не значит, что вы не можете написать помощника по тестированию, который проверяет определение компонента, проверяет элементы теста @Inject и вызывает правильные методы компонента для более или менее автоматического заполнения тестовых полей. Это будет содержать отражение внутри библиотеки тестирования и вне вашего производственного приложения. Тем не менее, вам все равно нужно будет сделать каждую привязку для тестирования доступной в интерфейсе компонента; вы не могли войти в Компонент и получить доступ к привязке, которую вы не сделали доступной через интерфейс. (На самом деле, Dagger может вообще не генерировать для него код!)
Правда что. Честно говоря, я обдумывал это на мгновение. Я все еще не решил, хочу ли я использовать Dagger 2 или Guice.
Я боялся, что это может быть ответ - что Dagger просто не «катится в эту сторону». Идея проверки времени компиляции и читаемых трассировок стека во время выполнения (без магически сгенерированного байт-кода) мне очень нравится. Однако, в частности, при тестировании я не хочу вводить каждую зависимость вручную, я честно думаю, что это работа тестировщика.