Когда использовать
Когда функция написана, а тестов нет — и лень/некогда придумывать кейсы. Роль — инженер по тестам. Результат: матрица тест-кейсов (happy/край/ошибка) + готовый код тестов + что осталось без покрытия.
Промт (бери и вставляй)
Ты — инженер по тестам. Напиши тесты для кода ниже.
КОД/ФУНКЦИЯ: «<ВСТАВЬ>». ФРЕЙМВОРК ТЕСТОВ: <напр. Vitest / Jest / pytest>.
Сначала выдай таблицу тест-кейсов: Что проверяем · Вход · Ожидаемый результат · Тип (happy / край / ошибка).
Покрой: типичный успешный путь; границы (пусто, ноль, максимум, длинный ввод); неверный ввод и ошибки; идемпотентность/повторный вызов, если применимо.
Потом — готовый код тестов по этой таблице, с понятными названиями. В конце отметь, какие места кода остались без покрытия.
Пример заполнения
Функция splitBill(total, people, tipPercent). Фреймворк: Vitest.
Ожидаемый ответ ИИ: таблица — happy «1000, 4, 10% → 275 на каждого»; край «people=1», «tip=0», «total=0»; ошибка «people=0 → бросает», «отрицательный total → бросает», «дробное округление». Затем код Vitest с describe/it, говорящими названиями (например «бросает при people=0»). В конце: «не покрыта валюта/локаль форматирования — если есть, добавьте».
Вариации
- TDD. «Напиши тесты ДО кода по этому описанию» — тесты как спецификация.
- Property-based. «Добавь property-тесты (fast-check/hypothesis): сумма частей = total».
- Только края. «Happy path есть, допиши пограничные и негативные кейсы».
Про-советы
- Сначала таблица, потом код — это не лишнее: вы увидите пробелы в кейсах до того, как сгенерится 200 строк тестов.
- Не доверяйте «ожидаемым результатам» вслепую — ИИ может посчитать неверно. Проверьте хотя бы пару значений руками.
- Тесты должны падать на реальном баге: вставив код с ошибкой, убедитесь, что сгенерированный тест её ловит, иначе это тест-пустышка.