Зачем тестировать, если код уже работает
Код «работает» — это не гарантия, что он работает правильно. Он работает на тех данных, которые вы проверили руками. А что с пустым вводом? С отрицательными числами? С миллионом записей? С двумя пользователями одновременно?
Тесты — это страховка. Как ремень безопасности: не нужен, пока не нужен. А когда нужен — спасает проект.
В Уроке 3 вы рефакторили код. Как убедиться, что после рефакторинга ничего не сломалось? Только тестами. Без тестов каждое изменение — рулетка.
3 типа тестов, которые AI генерирует лучше всего:
Unit-тесты — проверяют одну функцию изолированно. «Функция calculate_total с входом [100, 200, 300] должна вернуть 600». Самые быстрые и простые.
Интеграционные тесты — проверяют взаимодействие компонентов. «API-эндпоинт /api/orders создаёт заказ в базе данных и возвращает 201». Ловят баги на стыках.
Edge-case тесты — проверяют граничные случаи. «Что если список пуст? Что если дата — 29 февраля? Что если пользователь ввёл emoji в поле "имя"?» AI особенно хорош именно здесь — он предлагает случаи, о которых человек не думает.
Почему AI + тесты = идеальная пара: писать тесты вручную скучно и долго. Разработчики это ненавидят и откладывают. AI генерирует 10-20 тестов за минуту — без скуки и без прокрастинации.
Формула ТППГ и 3 стратегии тестирования с AI
Формула запроса тестов — ТППГ: Тестируемый код + Поведение + Покрытие + Границы. Запомните эту аббревиатуру — она структурирует каждый запрос на генерацию тестов.
Стратегия 1: «Покрой функцию» (Function Coverage)
Даёте AI функцию и просите: «Напиши unit-тесты для этой функции. Покрой: нормальный вход, пустой вход, невалидные данные, граничные значения, большие объёмы данных. Для каждого теста — имя, описание и assert.» AI выдаёт 8-12 тестов за 30 секунд. Разработчик тратит 30-60 минут на то же самое.
Стратегия 2: «Тесты по спецификации» (Spec-based Testing)
Не даёте код — даёте описание поведения: «Функция регистрации пользователя должна: принять email и пароль, проверить что email валидный и не занят, хешировать пароль, создать запись, вернуть токен. Напиши тесты для КАЖДОГО из этих шагов: успех и провал.» AI создаёт тесты по бизнес-требованиям — ещё до написания кода. Это TDD-подход: сначала тесты, потом код.
Стратегия 3: «Найди непокрытое» (Gap Analysis)
Даёте AI код + существующие тесты: «Вот код и текущие тесты. Что НЕ покрыто? Какие сценарии пропущены? Напиши дополнительные тесты для пропущенных случаев.» AI находит дыры в покрытии, о которых вы не думали: гонки, переполнение, некорректные типы, null/undefined.
Метрика: хорошее покрытие тестами — 70-85%. 100% — утопия и пустая трата времени. AI помогает дойти от типичных 20-30% до 70-80% за час вместо дня.
Как тесты от AI предотвратили баг на $200K
Ситуация: финтех-компания, система расчёта процентов по вкладам. Разработчик написал функцию расчёта и проверил вручную: 3 примера — всё правильно. Перед релизом решил попросить AI написать тесты.
AI сгенерировал 15 тестов. 12 прошли. 3 упали:
Тест 1: високосный год. 366 дней вместо 365 — расчёт процентов давал ошибку 0.27%. Звучит мелко? При 73,000 вкладов и средней сумме 400,000 руб — это переплата ~$200K в год.
Тест 2: микросумма. Вклад в 0.01 рубля — округление давало отрицательные копейки. Ещё ~$15K потенциальных потерь.
Тест 3: дата в прошлом. Дата закрытия вклада раньше даты открытия — функция не проверяла, выплачивала «отрицательные» проценты. Репутационный ущерб и жалобы в ЦБ.
Время написания тестов: 3 минуты (AI) + 20 минут (проверка и исправление багов). Стоимость предотвращённых потерь: $215K+ в год. ROI: бесконечный.
Вывод: тесты — не бюрократия, а деньги. AI делает их быстрыми и дешёвыми.
Генератор тестов по формуле ТППГ
Этот промпт использует формулу ТППГ: Тестируемый код + Поведение + Покрытие + Границы. Замените параметры в квадратных скобках:
Ты — QA-инженер с опытом 8+ лет. Пишешь надёжные, понятные тесты, которые ловят реальные баги. ТЕСТИРУЕМЫЙ КОД: [вставьте код функции или модуля] ПОВЕДЕНИЕ (что должен делать код): - [опишите ожидаемое поведение: вход → выход] - [бизнес-правила: условия, ограничения, исключения] ПОКРЫТИЕ (какие сценарии покрыть): 1. Happy path — нормальная работа с валидными данными 2. Edge cases — граничные значения (0, пустой, максимум, минимум) 3. Error cases — невалидные данные, ошибки, null/undefined 4. Integration — взаимодействие с другими компонентами (если есть) ГРАНИЦЫ (специфичные проверки): - [что точно НЕ должно произойти — например: «функция НЕ должна мутировать входной массив»] - [требования к производительности — «должна работать менее 100ms на 10K записях»] ФОРМАТ: - Фреймворк тестов: [pytest / Jest / Vitest / unittest] - Стиль: AAA (Arrange-Act-Assert) с понятными именами - Для каждого теста: название на [русском/английском], описание что проверяет, данные, ожидаемый результат - Группировка: отдельные блоки для happy path, edge cases, error cases
Начните с одной функции из своего проекта. Не тестируйте весь модуль сразу. Выберите самую критичную функцию — ту, где баг будет стоить дороже всего — и сгенерируйте для неё тесты. Потом двигайтесь к менее критичным.
🤖 Открыть в AI-модели
Мысль дня
Тесты — это не доказательство того, что код работает. Это документация того, КАК он должен работать. Когда через год вы забудете, зачем написали эту функцию — тесты напомнят.
Покройте функцию тестами с нуля
Сегодня вы применяете формулу ТППГ и 3 стратегии тестирования. Задание из трёх шагов:
Используйте код из Урока 2 (сложная функция с итеративной доработкой) или Урока 3 (отрефакторенный код). Если нет — попросите AI: «Сгенерируй функцию расчёта скидки: входные данные (сумма, тип клиента, день недели), логика (5 правил скидок), выход (итоговая сумма). Без тестов.»
Используйте промпт ТППГ из блока выше. Получите 10-15 тестов. Прочитайте каждый — понимаете ли вы, что он проверяет? Есть ли тесты, которые вы сами бы не написали? Обратите внимание на edge cases — обычно AI предлагает минимум 3-4 случая, о которых вы бы не подумали.
Отправьте AI код + тесты из Шага 2 и попросите: «Найди пропущенные сценарии. Что может пойти не так, но не проверяется? Напиши дополнительные тесты.» Сравните количество тестов до и после — обычно AI добавляет 30-50% дополнительных случаев. Это и есть разница между «покрытым» и «действительно надёжным» кодом.