Юнит тесты Все о них слышали. Некоторые утверждают, что якобы даже видели их своими глазами. Но сам их никто никогда не писал. А ты их писал? Или проверяешь у себя на проекте юниты разработчиков? Если серьезно - модульные тесты могут сделать нашу работу вдвое проще и в ДЕСЯТКИ раз быстрее. Достаточно только уговорить разработчиков их написать 😂 Внимание к юнитам - признак зрелости тестировщика. Начинающий QA хочет тестировать всё сам: хоть вручную, хоть автотестами. Подрастаешь - и упираешься в то, что один на себе не вывезешь. Нужно делегировать. И юниты - самый дешевый и быстрый способ это сделать. Что они реально проверяют? Не интеграцию с внешними сервисами, увы. Но вот это - легко: - Все валидации → 400 ошибка + сообщение - Отрицательная сумма в поле «сумма» → отклонение - Строка вместо числа в user_id → парсинг падает - Граничные значения: 0, 255, 256 для поля с лимитом 255 Уже минус 20-30% негативных кейсов Это всё логика. Она не требует БД, не ждет ответа от платежного шлюза. Пишется за 2 минуты и ловит 30% багов до того, как код ушел в тестирование. А ещё юниты проверяют позитивные кейсы. Да, не все. Но с ними меньше шансов пропустить баг на тестовый контур - упавшие тесты повалят пайплайн и не дадут залить этот код в мастер. Как это работает на практике Задача: добавить поле «скидка» в заказ, от 0 до 100%. Чек-лист от QA (булетами в тикете): - Скидка = 0 → принимается, цена не изменилась - Скидка = 100 → принимается, товар 0 рублей - Скидка = -1 → 400 ошибка - Скидка = 101 → 400 ошибка - Скидка = «пятьдесят» → 400 ошибка - Скидка = null → 400 ошибка - Скидка = 20 → товар за 200 ₽ вместо 250 ₽ (на 20% дешевле) Разработчик видит это ДО написания кода. Пишет юниты под каждый пункт. Ты как QA валидируешь один сценарий: создал заказ → применил скидку 20% → сумма пересчиталась. По факту ВСЁ уже покрыто. Ты не тратишь время на ручную проверку граничных значений — они падают сразу при сборке. Завтра на планировании спроси: «Какие кейсы из моего чек-листа ты можешь покрыть юнитами?» Не «напиши юниты». Не «увеличь покрытие». А конкретно — какие пункты. Это показывает, что ты не требуешь абстрактного «качества», а думаешь о процессе. И еще про покрытие Покрытие юнитами - тот еще холивар. Цифра процентов покрытия в юнитах НИЧЕГО не значит. Ну, то есть что-то значит, но это скорее референс, чем надежные данные. Не смотри на процент. Смотри на то, проверяют ли юниты условия, ветвления, граничные значения. Знать, как писать юниты — не обязательно. Но уметь составить чек-лист так, чтобы его легко было превратить в тесты - это крутой навык. Сейчас - дарю самое полезное видео по юнитам. Мне кажется, его поймет даже тот, кто на Java никогда не писал. Правда оно на английском. https://www.youtube.com/watch?v=vZm0lHciFsQ&t=473s