Правила хорошего UNIT-теста на примере java и spring boot

Всем привет, в этом видео покажу как делать unit тестирование типичного spring-boot приложения.
Проект на github:
github.com/Kirya522/medium-po...
Telegram канал для обратной связи:
t.me/kirya522
Лайв канал
/ @kirya522-live
Поддержать канал
pay.cloudtips.ru/p/f4934136
www.donationalerts.com/r/kiry...
Содержание:
0:00 - Введение
0:21 - Готовый пример
0:35 - Типичное SpringBoot приложение
1:10 - Как начинается unit тестирование
1:30 - Тестирование Repository
1:55 - Сколько методов столько и тестов
2:03 - Тесты не должны зависеть друг от друга
2:20 - Не инициализировать лишние зависимости
2:50 - Как назвать тест
3:10 - Содержание теста, модель AAA
3:40 - Когда использовать моки
4:20 - Самые типичные Unit тесты
5:12 - Тестирование Service
5:50 - Тестирование с моками зависимостей
6:15 - Полезные аннотации Mockito
7:05 - Настройка моков зависимостей
7:50 - Проверка вызовов через verify
8:30 - Как проверять void метод
9:03 - Тестирование Controller
9:13 - Тест с большим количеством моков
10:25 - Разница Unit и Integration тестов
11:00 - Кратко о SpringBootTest
11:40 - Зона ответственности Unit тестов
11:55 - Покрытие кода тестами
12:30 - Как читать отчет о покрытии
13:00 - Как происходит ревью тестов
13:40 - Возможная бессмысленность тестов
14:40 - Планы про нагрузочное тестирование

[@kirya522-dev]

Telegram канал с анонсами, обсуждениями, вопросами по видео. t.me/kirya522

[@user-uw7zl3gm5r]

спасибо большое за видео,приятно смотреть и слушать😃

[@faniskhalikov9736]

Спасибо! Концентрация полезности зашкаливает )) Как раз то, что мне нужно для пэт-проекта!

[@crew534]

Прекрасное видео, очень хорошая подача, благодарю за помощь

[@user-de4oq1uu9h]

Спасибо большое, очень много интересного узнал! Круто!!

[@DanChofire]

Спасибо лектору, очень крутая подача и материал.

[@raccoon8230]

Спасибо! Подача - 🔥

[@alexidrlen1538]

Очень круто объясняете, спасибо большое!!!

[@kirya522-dev]

Скоро сделаю по интеграционным тестам

[@mustFLEXboi]

Спасибо. Очень полезно

[@DuncanBatat]

Спасибо за видео! Очень помогло осознать цели юнит-тестов и начать разбираться с Moсkito.

[@kirya522-dev]

Рад был помочь

[@user-iu6yz6ck6h]

Подписался на канал. Спасибо за видео )

[@lexxx1994]

годно 👏

[@kifacapybara7309]

спасибо, очень полезно! ненавижу тестирование)

[@alexeikopendakov3348]

Казалось бы банальщина, но очень нужная! Спасибо!

[@69ultrapotato]

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

[@kirya522-dev]

Есть аннотации для тестов по типу @mock и в итоге тесты расширяются без особых проблем

[@kirya522-dev]

А тест на аннотацию и валидаторы можно написать один раз и их везде использовать

[@alexanderkadatskiy7986]

Привет! Отличное видео! А примера с интеграционными тестами с использованием спрингового контекста не планируется?

[@kirya522-dev]

Хотел сделать, но там гораздо больше надо рассказать. - mockmvc - конфиги - test containers

[@alexanderkadatskiy7986]

@@kirya522-dev Больше - не меньше) Можно на несколько видосов разбить

[@TheLordGamesTv]

@@kirya522-dev + про интеграционные хотелось бы видео, ждем

[@mr.whitesnow]

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

[@kirya522-dev]

Есть соглашение, что должно быть ровно наоборот. Тест создаёт данные и их же ищет, теперь вопрос почему. Потому что логика создания и наполнения данных тоже изменяется, программное управление созданием упрощает поддержку. А когда все данные есть и полное совпадение, это acceptance тестирование, самая дорогая часть пирамиды тестирования и самая не гибкая, нужна скорее в полноценных сценариях пользователя, а не в узких кусочках

[@mr.whitesnow]

согласен, что не удобно управлять тестовыми данными но в вашем случает тест проверяет не только то, что должен и может упасть раньше сути тесткейса в итоге менеджер смотрит результат с системе отчетности и возможно принимает неверное решение я эт не придумал, это из реальной жизни пример 😊

[@georgepro8481]

Привет! Для 8й джавы сработает так же?

[@kirya522-dev]

Да, вроде бы все что рассказал работает на 8

[@wildjoe6259]

Привет! Спасибо за видео! Такой вопрос, а mockMvc тесты не юзаете? типо mockMvc.perform(get("/api/some-url")) .andDo(print()) .andExpect(status().isOk()) .andExpect(content().json(obj.writeValueAsString(somePayload))); И к какому типу тестов нужно их отностить? (явно не юнит, но и не интеграционные, так как ответы от внешних систем мокируются)

[@kirya522-dev]

Привет, для mockmvc надо спринговый контекст, и идея там проверять взаимодействие как раз 2+ классов, как например сериализатор, десериализатор из json и ваша логика. Поэтому я отношу к интеграционным

[@SplashDmg2011]

Немного придерусь к вопросу: "тесты в проде" вообще не юзают, они прогоняются перед сборкой, а затем "вырезаются" из продового билда, они там уже не нужны)

[@stepan-klyukin]

А что делать если в результате работы метода у обьекта должно измениться одно поле? Мокать все поля кроме этого поля и делать бва таких обьекта но разным значением этого поля?

[@kirya522-dev]

Сделать свойство и доступ через геттер и его мокнуть

[@The_Vict0r]

Полезное видео, спасибо! А может EventBuilder лучше поместить на уровень сервисов? Это ведь уже работа с сущностями, а "контроллер должен быть тупым" :)

[@kirya522-dev]

А тут получается разделение ответственности, что есть core сервисы которые работают с сущностями, а контроллер отвечает именно за их представление, но на практике чаще это выражается ещё в один сервис который называется Api и в нем логика и маппинг

[@The_Vict0r]

@@kirya522-dev Ага. И этот Api находится в слое сервисов - я правильно понимаю?

[@kirya522-dev]

Предлагаю перейти от слоев к мавен модулям, чтобы было понятнее. Есть соответственно модули: - сервисов - Api И логика маппинга находится в модуле Api на слое сервисов, надеюсь не слишком запутал

[@The_Vict0r]

@@kirya522-dev Ну, я попробую понять )

[@Das.Kleine.Krokodil]

Нужно ли как то тестировать репозиторий если в нем нет кода? по типу такого: @Repository public interface EmployeeRepository extends JpaRepository { }

[@kirya522-dev]

фреймворки тестировать неблагородное дело

[@SplashDmg2011]

Я бы сказал немного иначе: тестированием фреймворков должны заниматься создатели этих фреймворков, нам повторно это делать не нужно)

[@SplashDmg2011]

Имена тестов типа "saveSmth_shouldDoSmth_whenSmth" и т.д. уже не стоит выдумывать, т.к. это трудно читается и вообще имя метода не для этого предназначено) в jUnit есть аннотация @DisplayName, которая позволяет человеческим языком (обычным текстом) написать, что именно проверяет тест

[@kirya522-dev]

Да, но тогда и аннотацию и имя надо поддерживать, а так называешь тесты в таком стиле и не заморачиваешься

[@SplashDmg2011]

@@kirya522-devимя поддерживать не надо, оно ни на что не влияет) можно хоть test1, test2 и т.д. называть. А вот читать строку "On save service should call repository.save()" гораздо приятней, чем ту конструкцию без пробелов и с подчеркиваниями) Мне кажется у тебя просто привычка уже выработалась просто. Вот у меня опыта поменьше, я почти сразу стал пользоваться @DisplayName, т.к. она уже появилась, когда я начал работать, и поэтому мне сразу этот метод кажется гораздо более удобным)) И это еще самый простой пример сценария я привел. А если тест проверяют какую-то сложную бизнес-логику, которую двумя словами не описать? Тогда придется городить название метода длиной в экран и читать его будет суперсложно. А в аннотации можно то же самое написать с пробелами и понятным языком) Но есть нюанс: аннотация появилась в JUnit5, и на легаси-проектах с JUnit4 использовать ее не получится)

[@Das.Kleine.Krokodil]

А нормально так контроллер тестировать, явно вызывая его методы? На проде так делаете, нет проблем? А то все материалы на которые натыкаюсь, используют @WebMvcTest и MockMvc Например как поступаете с BindingResult?

[@kirya522-dev]

Можно отдельно протестировать фреймворк если надо интеграционным тестом, сериализацию проверить, аутентификацию авторизацию, сделать один такой тест или парочку если различные механизмы есть. А в контроллерах больше не это делать, так тесты гораздо быстрее работают, если механизм сломается, сломаются тесты которые за него отвечают, но везде одинаковые подходы надо использовать. Что тоже звучит правильно Когда 40000+ тестов на контроллеры, поднятие контекста для запроса, сериализация и тд могут занимать 3/4 времени выполнения.

[@kirya522-dev]

Это все применимо для простых сценариев, если необходимо что-то сложное, например интеграцию проверить или весь flow, то надо писать интеграционный тест

[@kirya522-dev]

И дополнительно ролик только по unit тестам 😀

[@Das.Kleine.Krokodil]

@@kirya522-dev спасибо

[@nickivanov7903]

контроллер можно было тестить через web mvc test

[@kirya522-dev]

Да, но так получится уже интеграционный тест с контекстом🙂

[@alejandrospencio5524]

а приватные методы вы проверяете ?

[@kirya522-dev]

Приватные методы тестировать не надо, тестируется поведение публичных интерфейсов, приватные должны быть использованы в них и будут покрыты автоматически

[@kirya522-dev]

Но иногда есть плохой код, который неудобно рефакторить, то private метод становится package-private с аннотацией @VisibleForTesting и тестируется отдельно

[@alejandrospencio5524]

@@kirya522-dev спасибо, не знал )

[@alexricher2554]

У тебя очень хорошо получается объяснять! Было бы круто, если бы ты сделал видео на тему: как запустить простейшее spring boot приложение с БД. А то уже пару дней маюсь, никак не получается: бд создаётся, а таблица нет. Мб скрипт надо какой закинуть, чтобы он при запуске контейнера создавал таблицу? Не знаешь, как это вообще делается?

[@kirya522-dev]

Вообще несколько есть способов, самый простой liquibase

[@zhennik263]

Ну самый простой вариант это заставить hibernate создавать таблицы. А нормальный вариант это да, liqibase

[@alexricher2554]

@@kirya522-dev эх, как давно это было. Уже работаю на позиции Джуна)

[@user-gv3zn1us6s]

Зачем людям видеть лицо лектора? Это отвлекает от кода. Непонятное самолюбование

[@kirya522-dev]

Кому-то наоборот важно видеть, под всех не подстроюсь

[@user-gw6df6ns7e]

Он художник, он так видит. Кто то любит, чтобы ролик не был обезличен. Кто то наоборот.