Семен Киреков — Spring Data JPA. Антипаттерны тестирования

preview_player
Показать описание
Ближайшая конференция — Joker 2024, 9 октября (Online), 15–16 октября (Санкт-Петербург + трансляция).
— —
За свою карьеру спикер столкнулся с рядом (а некоторые даже попробовал) антипаттернов тестирования при использовании Spring Data JPA. Они не только не помогают, но и усложняют поддержку кода и вызывают раздражение.

В рамках доклада Семен расскажет вам о таких антипаттернах, как избыточный coupling на декларацию сущностей, лишние зависимости, best practices для создания тестовых данных и транзакционные сценарии. А также покажет паттерны, на которые следует их заменить, чтобы упростить жизнь при написании тестов.

Рекомендации по теме
Комментарии
Автор

Очень полезный доклад, все по делу и применимо, спасибо!

ranetka
Автор

Используешь рандомайзер в тестах - получаешь тесты, которые рандомно либо проходят либо не проходят. Это тоже антипаттерн.

avpmk
Автор

Спасибо за доклад. Применяю на практике )

AlexMogirevskiy
Автор

Доклад очень понравился, спасибо. + за интеграционные и End to End тесты.
Пример с проверкой статуса у робота, где exception прерывает транзакцию. Каждый раз, используя исключения для обработки штатных ситуаций я вижу с проблемы. Если это checked - не откатываются транзакции по умолчанию и нужно постоянно прописывать в сигнатуре по цепочке вызовов. Если unchecked - после рефакторинга может либо не хватить нового catch, либо останется старый мусорный. Я попробовал возвращать объект (статус + доп данные), обрабатывать через if или через switch (статус в enum и это гарантия перебора всех возможных ситуаций в клиентском коде). Это вполне решает задачу. Почему это не используется? Просто не java-style или этому есть еще какие-то причины?

kotbajan
Автор

Спасибо за доклад.

Идея с @With отлично подходит для не больших entity(или дто, если более глобально смотреть на тесты), для больших сущность возможно удобнее передавать лямбду, которой менять дефолтные поля, т.к. это избавит от дублирования в тестбилдере большого кол-ва полей, в которых проще допустить ошибку

dmitriipriporov
Автор

"Ну и это довольно verbose". Тьфу.

pklchrg
Автор

В итоге что стоит использовать вместо @DirtyContext? @BeforeEach с repository.deleteAll()?

maximisaev