Юнит тестирование Spring Bot в Docker и Яндекс облаке

Всем привет.

Меня зовут Евгений Фроликов я разработчик в АльфаСтрахование

В ходе работы над проектом в АльфаСтрахование пишем проект на микро сервисах и сложилось так что один из «микро сервисов» сильно разросся (но до монолита ему ещё далеко 🙂 ). Жили мы так долго и счастливо , пока не стали «переезжать» в облако, тут и начались приключения.

Переезд не чем особенно не запомнился для команды разработки только вопросами от DevOps насчёт портов и т.д. Замечу что все интеграционные тесты мы выпилили для того чтобы отвязаться от зависимости от других команд когда у них что то падает на тестовых стендах. Но стало происходить «магия» в JUnit тестах , а именно стали падать тесты. Падали они фантомное и не предсказуемо , лечилось до поры до времени это retraem pipeline , до тех пор пока эта проблема не стала блокером для выкладок изменений .

Дальше просто retraem

И так можно было «крутить рулетку» долго и упорно.

Стали разбираться (спасибо понимающему бизнесу за то что дали на это время) . Так примерно выглядели заголовки наших тестов (которых было ооочень много , так как мы иcпользуем Sonar).

@RunWith(SpringJUnit4ClassRunner.class) @SpringBootTest public class ContractStatusServiceTest {     @Autowired     private ContractStatusService contractStatusService;     @MockBean     private RsaInfoComponent rsaInfoComponent;     @MockBean     private ContractRepository contractRepository;

Давайте разберём «магические» анотации

1)@RunWith(SpringJUnit4ClassRunner.class) —Запуск контейнера Spring для выполнения модульного теста

2)@SpringBootTest -аннотация говорит Spring Boot пойти и найти основной класс конфигурации (например, с @SpringBootApplication) и использовать его для запуска контекста приложения Spring. SpringBootTest загружает полное приложение

3)@Autowired — Инжектит Bean;

И закралась мысль а почему мы используем @Autowired ведь его строго не рекомендуют использовать при разработке приложений , так как есть риск что он не успеет проинжектиться в поле.

Начались эксперименты такова рода.

@RunWith(SpringRunner.class) @SpringBootTest @RequiredArgsConstructor public class  ComponentTestTest {     // @Autowired     private final ComponentTest componentTest;      

То есть попытка проинжектить бин как в приложение , через конструктор

1)@RequiredArgsConstructor — Аннотация Lombok для автоматического создания конструкторов из полей final.

Но…..

java.lang.Exception: Test class should have exactly one public zero-argument constructor  	at 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;

Давайте разберёмся что тут происходит и всём принципиальная разница

1)@RunWith(MockitoJUnitRunner.class) — Заполняет заглушками наш Bean , а не поднимается контекст (подробнее можно почитать в доках )

2)@Mock — сама заглушка

3)@InjectMocks — создаёт Bean и передаёт в конструктор заглушки

И всё «звалось»))

Плюсы :

1)У нас в разы ускорились тесты при деплоях (так как контекст не поднимается)

2)Мы перестали ловить и бояться не проинжектеных бинов

Минусы:

1)Пришлось переписывать все тесты