Всем привет.
Меня зовут Евгений Фроликов я разработчик в АльфаСтрахование
В ходе работы над проектом в АльфаСтрахование пишем проект на микро сервисах и сложилось так что один из "микро сервисов" сильно разросся (но до монолита ему ещё далеко :) ). Жили мы так долго и счастливо , пока не стали "переезжать" в облако, тут и начались приключения.
Переезд не чем особенно не запомнился для команды разработки только вопросами от DevOps насчёт портов и т.д. Замечу что все интеграционные тесты мы выпилили для того чтобы отвязаться от зависимости от других команд когда у них что то падает на тестовых стендах. Но стало происходить "магия" в JUnit тестах , а именно стали падать тесты. Падали они фантомное и не предсказуемо , лечилось до поры до времени это retraem pipeline , до тех пор пока эта проблема не стала блокером для выкладок изменений .
тест 1 запуск
Дальше просто retraem
тест 2 запуск
И так можно было "крутить рулетку" долго и упорно.
Стали разбираться (спасибо понимающему бизнесу за то что дали на это время) . Так примерно выглядели заголовки наших тестов (которых было ооочень много , так как мы иcпользуем Sonar).
@RunWith(SpringJUnit4ClassRunner.class)@SpringBootTestpublic class ContractStatusServiceTest { @Autowired private ContractStatusService contractStatusService; @MockBean private RsaInfoComponent rsaInfoComponent; @MockBean private ContractRepository contractRepository;
Давайте разберём "магические" анотации
-
@RunWith(SpringJUnit4ClassRunner.class) -Запуск контейнера Spring для выполнения модульного теста
-
@SpringBootTest -аннотация говорит Spring Boot пойти и найти основной класс конфигурации (например, с @SpringBootApplication) и использовать его для запуска контекста приложения Spring. SpringBootTest загружает полное приложение
-
@Autowired - Инжектит Bean;
И закралась мысль а почему мы используем @Autowired ведь его строго не рекомендуют использовать при разработке приложений , так как есть риск что он не успеет проинжектиться в поле.
Начались эксперименты такова рода.
@RunWith(SpringRunner.class)@SpringBootTest@RequiredArgsConstructorpublic class ComponentTestTest { // @Autowired private final ComponentTest componentTest;
То есть попытка проинжектить бин как в приложение , через конструктор
1)@RequiredArgsConstructor - Аннотация Lombok для автоматического создания конструкторов из полей final.
Но.....
java.lang.Exception: Test class should have exactly one public zero-argument constructorat org.junit.runners.BlockJUnit4ClassRunner.validateZeroArgConstructor(BlockJUnit4ClassRunner.java:171)at org.junit.runners.BlockJUnit4ClassRunner.validateConstructor(BlockJUnit4ClassRunner.java:148)at org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:127)...
а жаль.
Дальше стали приходить осознавание , а зачем мы поднимаем контекст всего приложения для простых тестов и вспомнили про Mock
@RunWith(MockitoJUnitRunner.class)public class CrossProductServiceTest { @InjectMocks private CrossProductService crossProductService; @Mock private KaskoService kaskoService; @Mock private CrownVirusOfferService crownVirusOfferService;
Давайте разберёмся что тут происходит и всём принципиальная разница
-
@RunWith(MockitoJUnitRunner.class) - Заполняет заглушками наш Bean , а не поднимается контекст (подробнее можно почитать в доках )
-
@Mock - сама заглушка
-
@InjectMocks - создаёт Bean и передаёт в конструктор заглушки
И всё "звалось".
Плюсы :
-
У нас в разы ускорились тесты при деплоях (так как контекст не поднимается)
-
Мы перестали ловить и бояться не проинжектеных бинов
Минусы:
-
Пришлось переписывать все тесты
