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

Всем привет, в этом видео покажу как делать unit тестирование типичного spring-boot приложения.

Проект на github:

Telegram канал для обратной связи:

Лайв канал

Поддержать канал

Содержание:
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 - Планы про нагрузочное тестирование

[kirya-dev]

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

[alexsecret]

респект за показ-рассказ) ощущение что я писал тесты всю жизнь!) ну а теперь приступим...

[faniskhalikov]

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

[uwzlgmr]

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

[crew]

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

[deoquuh]

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

[DanChofire]

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

[alexidrlen]

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

[iuyzckh]

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

[DuncanBatat]

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

[ultrapotato]

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

[kifacapybara]

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

[stepan-klyukin]

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

[Das.Kleine.Krokodil]

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

[georgepro]

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

[alexanderkadatskiy]

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

[alexeikopendakov]

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

[wildjoe]

Привет! Спасибо за видео! Такой вопрос, а mockMvc тесты не юзаете? типо
.andDo(print())
.andExpect(status().isOk())


И к какому типу тестов нужно их отностить? (явно не юнит, но и не интеграционные, так как ответы от внешних систем мокируются)

[mr.whitesnow]

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

[The_Victr]

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