Чтобы создавать качественные тесты с помощью ИИ, начинайте с требования и независимого тестового оракула, а не только с реализации. Сначала спроектируйте нормальные, граничные и ошибочные сценарии, затем проверьте фикстуры, моки, утверждения и эффекты и убедитесь с помощью контролируемой ошибки, что важный тест действительно способен упасть.

Цель — доказательство, а не большее число тестов. Сначала ограничьте задачу по базовому рабочему процессу с ИИ, а каждый созданный тест рассматривайте как код для ревью.

Ключевые выводы

Зафиксируйте требование и исходный результат до генерации.

Определите наблюдаемый критерий успеха и отказа каждого случая.

Сначала спроектируйте матрицу, затем просите тестовый код.

Отдельно проверяйте фикстуры, моки, утверждения, очистку и детерминизм.

Временной контролируемой ошибкой докажите чувствительность теста.

Как создавать качественные тесты с помощью ИИ, не копируя реализацию?

Передайте модели публичный контракт, примеры, ограничения и существующие соглашения о тестах и попросите сначала предложить случаи, а не код. В учебнике GitHub по тестированию сказано, что помощники могут помочь с модульными и интеграционными тестами, но сложным сценариям нужны более подробные стратегии, а сгенерированные наборы всё равно нужно проверять на пропущенные случаи.［1］

Слабый запрос звучит так: «Напиши модульные тесты для этой функции». Модель может зеркально повторить ветви, проверять приватные вызовы или воспроизвести то же непонимание, что и реализация. Сильный запрос говорит, какое поведение важно, какие интерфейсы публичны, какие ошибки ожидаемы и что должно остаться совместимым.

Держите раздельно четыре артефакта:

Артефакт	На какой вопрос отвечает
Требование	Какое поведение обещано?
Оракул	Как мы узнаем, что результат правильный?
Матрица случаев	Какие различные условия нужно проверить?
Тестовый код	Как репозиторий выполняет эти проверки?

Если оракул — это просто «совпадает с текущей реализацией», тест не сможет показать, что реализация ошибочна.

Шаг 1. Зафиксируйте требование и надёжную базу

Сформулируйте требование в наблюдаемых терминах. «Отклонять отрицательную длительность с ошибкой InvalidDuration, не меняя обработку корректных секунд и минут» — проверяемо. «Улучшить проверку длительности» — нет.

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

Если код незнаком, сначала проследите нужный путь по доказательствам. Генерировать тесты стоит после того, как вы знаете точку входа, зависимости, состояние и внешние эффекты.

Определите оракул вне реализации

Хорошие источники оракула — публичный контракт API, спецификация протокола, схема, критерий приёмки, ранее одобренное поведение или независимо рассчитанный результат. Для парсера оракулом может быть явная таблица «вход — выход». Для проверки авторизации — матрица политик. Для финансового расчёта может понадобиться отдельно проверенная формула с примерами.

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

Шаг 2. Постройте матрицу нормальных, граничных и ошибочных случаев

Сначала попросите названия случаев и обоснование. Каждая строка должна менять одно значимое условие и называть ожидаемый наблюдаемый результат.

Используйте как минимум такие категории:

Нормальные: типичные корректные входы и совместимый выход.
Граничные: пустое значение, ноль, минимум, максимум, точный порог и шаг за ним.
Ошибочные: некорректный формат, отсутствие прав, недоступная зависимость, тайм-аут и отклонённая операция.
Состояние: первый вызов, повторный вызов, дублирующийся ввод, частично существующее состояние и повтор после сбоя.
Взаимодействие: зависимость вызвана с правильными данными, не вызвана при отказе, очистка выполнена.
Атакующие: текст, похожий на внедрение инструкций, слишком большой ввод, выход за пределы каталога или инструкции в недоверенном документе — если это относится к делу.

Не добавляйте категории механически. Чистой функции форматирования могут быть не нужны случаи сетевых сбоев, а обработчику очереди подтверждение и повторная обработка важнее десятков вариантов строк.

Матрица — инструмент планирования. Она не означает покрытия, пока тесты не выполнены и не проверена их способность обнаруживать ошибку.

Не дублируйте один случай под разными названиями

Десять значений, проходящих по одной ветви, обычно составляют один класс эквивалентности, а не десять независимых защит. Попросите модель объяснить, какой уникальный риск обнаруживает каждый случай. Удаляйте строку, если она не даёт отдельного наблюдения.

В руководстве GitHub по генерации модульных тестов рекомендуется дать помощнику код и ясные инструкции, а затем проверить результат.［2］ Добавьте шаг с матрицей случаев, чтобы оценить замысел до того, как синтаксис придаст ему законченный вид.

Шаг 3. Передайте минимальный безопасный контекст

Передайте требование, публичный интерфейс, нужную реализацию, соседние существующие тесты, построители тестовых данных и точную команду запуска. Добавьте принятые в репозитории правила именования, работы с асинхронным кодом, временных файлов, изоляции базы данных и очистки.

Не вставляйте реальные записи клиентов, выгрузки из рабочей базы, секреты, подписанные URL или учётные данные. Создайте синтетические тестовые данные, сохраняющие форму и граничное условие: реалистичным данным не нужны реальные личности.

Попросите модель в первом проходе не добавлять зависимости, не перегенерировать массово снимки (snapshots), не ослаблять проверки и не менять рабочий код. Если тест трудно написать из-за сильной связанности кода, запишите это ограничение дизайна отдельно, а не прячьте его за большим моком.

Шаг 4. Проверьте фикстуры, моки и утверждения

Сгенерированные тесты часто выглядят правдоподобно, но доказывают очень мало. Проверяйте тест в порядке выполнения.

Фикстура должна создавать нужное условие

Проверьте типы, единицы, часовые пояса, кодировки, значения по умолчанию, идентификаторы и связи. Граничный тест на случайно нормализованных данных может так и не дойти до границы. Делайте построители данных явными там, где скрытые значения по умолчанию могут изменить смысл.

Мок не должен заменять проверяемое поведение

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

Слишком жёсткие проверки порядка вызовов ломаются при безобидном рефакторинге. Слишком слабые моки могут пропустить неавторизованные или повторные эффекты. Выбирайте взаимодействия, выражающие контракт, — например, «после неудачной проверки запись не выполняется», — а не каждый вызов приватной вспомогательной функции.

Утверждение должно различать правдоподобные результаты

Утверждение должно отличать правильный результат от правдоподобного неправильного. result is not None, «исключения нет» или широкий снимок могут проходить для множества неверных результатов. Проверяйте поля, тип ошибки, изменение состояния, эффекты, порядок, дубликаты и лишние элементы.

Материалы GitHub об ответственном использовании предупреждают, что результаты ИИ могут быть неточными, неполными или не соответствовать цели и требуют человеческого контроля.［3］ Это относится и к тестам.

Шаг 5. Сначала запустите базу, затем кандидатные тесты

Прежде чем добавлять файлы, запустите ближайшую надёжную группу тестов. Затем добавьте минимальный связный набор новых тестов и запустите только его. Сбой может означать реальный дефект, неверный оракул, сломанные тестовые данные или допущение о среде — не меняйте проверку сразу.

Разбирайте сбой в таком порядке:

Перечитайте требование и ожидаемое наблюдение.
Проверьте тестовые данные и убедитесь, что выполнялся нужный путь.
Проверьте, изолирован ли тест и детерминирован ли он.
Изучите реализацию и собранные доказательства.
Неоднозначное поведение продукта передайте его владельцу.

Если сбой выявил дефект реализации, сохраните случай и перейдите к отладке с ИИ по доказательствам. Не переписывайте тест так, чтобы ошибка выглядела правильным поведением.

Шаг 6. Докажите, что важный тест способен упасть

Проходящий тест может так и не дойти до нужной ветви или проверять константу. Для каждого ценного случая внесите временную контролируемую ошибку: поменяйте сравнение, пропустите проверку, верните не то поле или уберите ожидаемый эффект. Тест должен упасть по задуманной причине.

Сразу удалите ошибку и убедитесь, что тест снова проходит. Проверьте diff, чтобы изменение не осталось в коде. Такая локальная проверка чувствительности не заменяет полноценного мутационного тестирования, но выявляет пустые проверки и нерелевантные тестовые данные.

Осторожнее со снимками: снимок доказывает лишь совпадение с одобренным файлом. Проверяйте смысловые изменения, а не принимайте большое обновление только потому, что изменился сгенерированный вывод.

Шаг 7. Проверьте детерминизм, очистку и место в наборе

Запускайте новый тест несколько раз, если задействованы время, случайность, параллельность, локаль, порядок или внешние ресурсы. Контролируйте часы и начальные значения генератора случайных чисел, когда контракт это допускает. Используйте временные каталоги и изолированное состояние базы данных и проверяйте очистку как при успехе, так и при сбое.

Расширяйте проверку слоями:

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

Не утверждайте, что локальный успех доказывает работу в другой операционной системе, конфигурации рабочей среды, внешнем сервисе или при развёртывании. NIST SSDF рассматривает тестирование и ревью как часть набора практик безопасной разработки, а не как единственный сигнал завершения.［4］

Шаг 8. Проверьте тестовый патч как поддерживаемый код

Применяйте чек-лист ревью кода от ИИ и к тестам: проверьте изменения зависимостей, скрытый доступ к сети, небезопасные временные пути, реальные учётные данные, избыточные тестовые данные, медленные повторы и широкие права.

Будущий разработчик должен быстро ответить на три вопроса:

Какой контракт защищает этот тест?
Какое изменение должно заставить его упасть?
Какие детали подготовки существенны, а какие случайны?

Предпочитайте содержательные названия, описывающие поведение, и короткие комментарии к тестовым данным, а не пересказ сеанса генерации. Тест и требование должны оставаться полезными и после того, как разговор с ИИ закончится.

Что нужно зафиксировать после генерации тестов с помощью ИИ?

Зафиксируйте требование, оракул, добавленные сценарии, выполненные команды, использованные контролируемые дефекты и непроверенные среды. Отделите новые сбои от базовых. Перечислите моки и объясните, какую реальную границу заменяет каждый из них.

Если ИИ предлагает и патч рабочего кода, проведите его как отдельное разрешение по рабочему процессу малой кодовой задачи. Тесты могут направлять изменение, но их генерация не разрешает менять описываемое ими поведение.

Итоги

Начинайте с наблюдаемого требования и независимого оракула.
Проектируйте нормальные, граничные, ошибочные случаи, случаи состояния и взаимодействия, а при необходимости — атакующие.
Используйте синтетические минимальные фикстуры и моки только на границах.
Проверяйте способность утверждений различать правильный и правдоподобный неверный результат.
Докажите отказ на контролируемой ошибке и расширяйте проверки слоями.

Часто задаваемые вопросы (FAQ)

Может ли ИИ автоматически создать полный набор тестов?

Он быстро предлагает много случаев и пишет синтаксис, но полнота зависит от требований, рисков системы, сред и человеческого суждения. Считайте сгенерированные тесты кандидатами, а не сертификатом.

Генерировать тесты из реализации или требований?

Используйте оба источника, но правильность определяют требования. Реализация помогает найти ветви, а не задаёт единственный оракул.

Чем выше покрытие, тем лучше?

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

Можно ли позволить ИИ обновлять снимки при падении тестов?

Только после смыслового просмотра разницы и подтверждения нового результата. Массовое обновление снимков может скрыть регрессию, объявив её ожидаемым поведением.

Сколько нужно мокировать?

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

Доказывают ли зелёные тесты от ИИ исправление ошибки?

Нет. Они подтверждают лишь выполненные сценарии в данной среде. Сохраните исходное воспроизведение, проверьте патч, запустите нужные более широкие проверки и запишите, что осталось непроверенным.

Что делать при неоднозначном требовании?

Остановитесь и попросите владельца продукта, протокола или политики определить контракт. Не позволяйте модели выбирать между правдоподобными исходами или закреплять случайность как постоянное поведение.

Можно ли хранить в тестах данные из рабочей среды?

Нет. Используйте синтетические или одобренные обезличенные данные без ключей, записей клиентов и реальных сервисов.

Рекомендуемые статьи:

Отказ от ответственности: материал содержит общие рекомендации по тестированию. Требования к безопасности, качеству и выпуску зависят от системы и организации; критичный код требует квалифицированной проверки.

Источники:

GitHub Docs — Writing tests with GitHub Copilot — https://docs.github.com/en/copilot/tutorials/write-tests
GitHub Docs — Generating unit tests — https://docs.github.com/en/copilot/tutorials/copilot-cookbook/testing-code/generate-unit-tests
GitHub Docs — Application card for Copilot inline suggestions — https://docs.github.com/en/copilot/responsible-use/inline-suggestions
NIST — Secure Software Development Framework — https://csrc.nist.gov/pubs/sp/800/218/final

Sources checked 24 августа 2026 г.

Как создавать качественные тесты с помощью ИИ