Юнит тесты
Все о них слышали. Некоторые утверждают, что якобы даже видели их своими глазами.
Но сам их никто никогда не писал.
А ты их писал? Или проверяешь у себя на проекте юниты разработчиков?
Если серьезно - модульные тесты могут сделать нашу работу вдвое проще и в ДЕСЯТКИ раз быстрее. Достаточно только уговорить разработчиков их написать 😂
Внимание к юнитам - признак зрелости тестировщика. Начинающий 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
