Генерация unit- и e2e-тестов с ИИ: как выбрать инструменты

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

Главное условие выбора — тесты должны находить настоящие дефекты. Количество созданных файлов, рост покрытия и зеленый запуск сами по себе этого не доказывают: тест может успешно повторять ту же ошибку, что и код. Эта статья поможет составить протокол сравнения, определить критерии приемки сгенерированных тестов и установить правила автоматического «лечения», которое не скрывает ошибки.

Unit- и e2e-тесты решают разные задачи

Unit-тест проверяет отдельную функцию или класс: для таких входных данных ожидается такой результат. Обычно он запускается быстро и не требует браузера; внешние зависимости при необходимости заменяют заглушками. Если тест использует настоящую базу или сеть, это другой и более дорогой сценарий, который нужно оценивать отдельно. Ценность unit-теста — быстро показать, что конкретная логика сломалась, и подсказать где.

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

Поэтому требования к ИИ-инструментам различаются. Для unit-тестов нужны доступ к коду, типам, существующим тестам и возможность запускать их. Для e2e — доступ к работающему приложению, умение находить элементы страницы и проверять состояние не только на экране, но и в системе: сохранился ли заказ с правильной суммой.

Какие классы инструментов сравнивать

Вместо рейтинга продуктов полезнее понять классы инструментов и критерии сравнения.

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

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

Браузерный агент. Работает с интерфейсом: исследует страницы, пишет сценарии и обновляет их. В Playwright предусмотрены три роли: planner исследует приложение и составляет план в Markdown; generator превращает план в исполняемые тесты, проверяя локаторы и assertions во время прохождения; healer запускает упавший тест и предлагает исправить локатор, ожидание состояния или тестовые данные. Изменение ожидаемого бизнес-результата требует отдельной проверки человеком.

Управляемый сервис. Внешняя платформа хранит и запускает тесты сама. Она снимает часть инфраструктурных задач, но добавляет зависимость от поставщика и вопросы доступа к тестовой среде.

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

Учебная таблица сравнения

Заполняйте таблицу для своего стека; это не оценка конкретных продуктов.

Как подготовить контекст

ИИ не знает, как должен работать ваш бизнес. Если передать ему только код, он может вывести ожидание из кода и проверить, что код делает то, что уже делает. До генерации подготовьте:

• Бизнес-контракт. Что функция или сценарий должны гарантировать: «скидка не больше 30%», «заказ с нулевой суммой не создается», «после оплаты статус — „оплачен“».
• Фикстуры. Подготовленные тестовые данные: товары, клиенты, тарифы. Они должны быть стабильными, известными и не содержать реальных персональных данных.
• Допустимые побочные эффекты. Что тесту разрешено менять: записи в тестовой базе — да, письма реальным клиентам — нет.
• Тестовые учетные записи с разными ролями: администратор, менеджер, обычный клиент.
• Существующие соглашения. Структура тестов, именование, вспомогательные функции и подход к заглушкам. Новые тесты должны выглядеть так, будто их написала команда.

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

Как принимать unit-тесты

Принимайте сгенерированный unit-тест по тем же правилам, что и написанный человеком, добавив несколько специальных проверок.

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

Независимость ожидаемого результата. Ожидаемое значение должно следовать из контракта или ручного расчета, а не из вызова той же функции. Тест вида «результат функции равен результату функции» ничего не проверяет.

Учебный пример. Контракт функции скидки: «для заказов от 10 000 гривен скидка 5%, но не больше 1 000 гривен». В коде ошибка: ограничение в 1 000 гривен не применяется. Модель, которая видит только код, может написать тест «заказ на 30 000 гривен → скидка 1 500 гривен», потому что именно это сейчас считает код. Тест пройдет и закрепит ошибку. Тест, построенный по контракту, ожидает 1 000 гривен и упадет — то есть обнаружит дефект до клиента. Передавайте модели контракт отдельно от кода и прямо просите брать ожидаемые значения из него. На ревью спрашивайте не только «проходит ли тест», но и «откуда взялось ожидаемое число». Если ответ — «из результата функции», тест нужно переписать.

До генерации полезно попросить модель перечислить важные граничные случаи. Список легко проверить: есть ли ровно 10 000 гривен, сумма чуть ниже порога, сумма, где 5% равны лимиту, отрицательное или нулевое значение. Пропуск виден сразу, а не после чтения сотен строк тестового кода.

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

Проверьте способность найти дефект. Внесите ошибку намеренно — поменяйте знак сравнения, удалите проверку, измените константу — и убедитесь, что тест падает. На этой идее основано mutation testing: специальные инструменты автоматически вносят такие изменения и считают, сколько из них обнаружили тесты.

Показательный пример автоматической фильтрации — внутренняя система генерации тестов, описанная в 2024 году. Она последовательно проверяла, собирается ли тест, проходит ли он стабильно и повышает ли покрытие. В оценке на двух конкретных продуктах 75% сгенерированных тестов собрались, 57% прошли стабильно, а 25% увеличили покрытие. На внутренних тестовых сессиях система улучшила тесты для 11,5% классов, к которым ее применяли, а инженеры приняли 73% ее рекомендаций в рабочий код. Это внутренний инструмент для конкретных кодовых баз; такие цифры нельзя переносить на ваш репозиторий. Практический вывод проще: фильтруйте генерации и просматривайте уже отфильтрованный результат, а не принимайте все подряд.

Как принимать e2e-тесты

В e2e добавляются вопросы стабильности.

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

Контролируемые данные. Тест создает нужные данные или использует заранее подготовленные и не зависит от того, что осталось после других тестов.

Ожидание состояния вместо паузы. Тест ждет появления элемента или смены статуса, а не «спит» фиксированные пять секунд. Паузы одновременно замедляют и делают тесты нестабильными.

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

Проверка состояния системы, не только экрана. Надпись «Спасибо за заказ» не доказывает, что заказ сохранился с правильной суммой.

Учебный сценарий e2e: оформление заказа

Сценарий: клиент добавляет в корзину два товара, применяет промокод и оформляет заказ. Тест проверяет правильную сумму на экране подтверждения и отдельно — через тестовый API или базу данных — что заказ сохранен со статусом «ожидает оплаты» и той же суммой.

После обновления приложения возможны две ситуации. В первой кнопку «Оформить» переименовали в «Подтвердить заказ». Тест падает, потому что не находит кнопку. Обновить локатор — нормальный фикс: поменялся интерфейс, а не поведение. Во второй после обновления сумма заказа стала на 50 гривен больше, потому что промокод перестал применяться. Тест падает на проверке суммы. Нельзя поменять ожидаемую сумму, чтобы тест снова прошел: он сделал именно то, для чего нужен, — нашел дефект.

Даже если после генерации выросло покрытие строк, это не доказывает отсутствие дефектов. Покрытие показывает, какие строки выполнились, а не правильны ли проверки.

Как оценивать автоматическое исправление

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

В Playwright агент-healer повторяет шаги упавшего теста, ищет эквивалентные элементы или сценарии в интерфейсе и предлагает исправление: обновить локатор, скорректировать ожидание состояния или тестовые данные. Он запускает тест повторно, пока тот не пройдет или пока не сработают ограничения. Если агент считает, что сломана сама функциональность, он может пометить тест как пропущенный. Это разумно, но пропущенный тест — тоже сигнал для разбора, иначе дефект исчезнет из поля зрения.

Установите четкие правила:

• Можно без дополнительного согласования: обновить локатор, если изменился только интерфейс; заменить фиксированную паузу ожиданием состояния; поправить устаревшие тестовые данные.
• Нужно объяснение и согласование: любое изменение ожидаемого результата — суммы, статуса, количества или текста. Автор должен объяснить, почему изменилась потребность, и указать решение, которое это подтверждает.
• Запрещено: незаметно подгонять проверку под текущий результат; массово пропускать тесты без разбора; удалять падающий тест без задачи на выяснение причины.

Предложенные ИИ-исправления нужно проверять человеком; существующие тесты помогают убедиться, что поведение не изменилось. Для тестов правило то же: изменение проверки меняет контракт и проходит ревью.

Итог и первые шаги

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

Что можно сделать в своем проекте:

1. Записать бизнес-контракт одного модуля: что функции гарантируют и что запрещено.
2. Выбрать два-три инструмента разных классов и дать им одинаковую задачу на одном коде.
3. Внести несколько известных дефектов для каждого набора сгенерированных тестов и посчитать, сколько тесты обнаружили.
4. Выбрать один критичный e2e-сценарий, например оформление заказа, и проверять состояние в системе, а не только на экране.
5. Записать правила автоматического исправления: что можно, что нужно согласовать, что запрещено.
6. Настроить уведомления о тестах, помеченных как пропущенные, и разбирать каждый случай.

Проще всего начать сравнение инструментов с одним модулем и одним критичным сценарием. Если нужно выбрать варианты, закрепить критерии приемки и определить, кто будет сопровождать сгенерированные тесты в CI, команда BotLabs может разобрать ваш процесс и задать границы пилота.

Частые вопросы