Может ли AI писать тест-кейсы по исходному коду? Что работает на практике

Да — AI уже умеет прочитать репозиторий и написать к нему тест-кейсы, а часть инструментов ещё и запускает их по расписанию. Но «AI пишет тесты» — это три разные вещи: генерация юнит-тестов по коду, проверка end-to-end сценариев на работающем приложении и платформы, которые соединяют то и другое с выполнением пайплайнов. На практике хорошо работает первый черновик тестов для файлов, у которых тестов нет: под конвенции проекта, скомпилированный, прогнанный через линтер и отданный человеку на ревью в pull request. Плохо работает доверие без запуска. Ниже рассказываем, как это делает наш Testing AI Assistant, где генерация тестов по исходному коду ломается и чем этот подход отличается от инструментов, которые чаще всего называют AI-ассистенты.

Короткий ответ: да, но «AI пишет тесты» — это три разные вещи

Первая группа — генераторы юнит-тестов. Они берут класс или функцию и создают тест, который её вызывает и проверяет результат. Старые инструменты этой группы, например EvoSuite для Java, перебирают пространство возможных входных данных алгоритмически; новые используют языковые модели или обучение с подкреплением. Их сила — масштаб: они быстро покрывают тестами много кода. Слабость — ожидания они выводят из того, что код делает сейчас, а не из того, что он должен делать.

Вторая группа — end-to-end агенты. Они начинают с работающего приложения, иногда с описания требований, и проверяют сценарии глазами пользователя: вход, корзина, форма. Исходный код для них — контекст, а не главный вход.

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

Как Testing AI читает исходный код, прежде чем что-то написать

Всё начинается с доступа. Организация добавляет токен Токен — это фрагмент текста, обычно часть слова: ИИ-модели измеряют в токенах и длину запроса, и стоимость, поэтому счёт приходит за токены, а не за вопросы. Полное определение → провайдера — GitHub, GitLab или Bitbucket, — и с этого момента любой проект организации может пользоваться мастером генерации тестов. Никто не вставляет код вручную: AI-сервис получает его через API API — это интерфейс, через который две системы обмениваются данными автоматически, без выгрузок в Excel и копирования руками. Полное определение → провайдера.

Первый шаг — анализ проекта. Система получает дерево файлов, читает до 15 конфигурационных файлов (package.json, tsconfig.json, конфиги Jest, ESLint и подобные) и находит существующие тестовые файлы. По ним агент строит профиль проекта: язык, тестовый фреймворк, пакетный менеджер, каталоги исходников, шаблоны именования тестов. Профиль сохраняется, поэтому следующие сессии для того же проекта не анализируют репозиторий заново.

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

От кода к тест-кейсам: предложение, одобрение, генерация

По профилю система выбирает файлы из каталогов исходников, пропускает те, у которых уже есть тесты, файлы объявлений типов и index-файлы, и берёт до 30 файлов с поддерживаемыми расширениями (TypeScript, JavaScript, Python, Java, Go, Rust). Можно указать область, на которой агенту сосредоточиться, например «модуль авторизации». Это хорошая практика: 30 файлов, выбранных из всего репозитория, говорят о проекте меньше, чем 30 файлов из одного модуля.

Агент предлагает список тестовых файлов. У каждого пункта есть целевой файл, путь теста по конвенции проекта, тип теста (юнит, интеграционный или E2E), описание того, что тест покроет, обоснование, приоритет и оценка числа тест-кейсов. Высокий приоритет получает критическая логика без тестов, средний — важный код с частичным покрытием, низкий — то, что неплохо бы иметь.

Здесь первая точка контроля человеком: ничего не генерируется, пока кто-то не одобрит пункты. Можно одобрить всё или выбрать несколько.

Генерация идёт файл за файлом, последовательно. Для каждого файла система собирает контекст: сам целевой файл, его локальные импорты (до 20 файлов — типы, интерфейсы, вспомогательные функции), до трёх существующих тестов проекта как образец стиля и вычисленные относительные пути импорта от тестового файла к исходникам. Затем модель пишет тест, код проходит очистку (удаление markdown-разметки, неиспользуемых импортов и переменных, типичных проблем с типами), а второй проход модели исправляет пути импорта и ошибки типов.

flowchart TB
  RE["Репозиторий<br/>GitHub · GitLab · Bitbucket"] --> PR["Профиль проекта<br/>язык, фреймворк, шаблоны тестов"]
  PR --> PO["Предложение<br/>до 30 исходных файлов"]
  PO --> AP{"Человек одобряет<br/>пункты"}
  AP --> GE["Генерация<br/>файл за файлом"]
  GE --> VA["Валидация<br/>tsc и ESLint"]
  VA -->|ошибки, до 3 попыток| GE
  VA --> RV["Ревью и правка<br/>в браузере"]
  RV --> CM["Ветка ai/test-gen<br/>коммит и pull request"]
  CM --> CI["Ваш CI запускает тесты"]

Валидация: «компилируется» — не то же самое, что «проходит»

Когда все файлы сгенерированы, система клонирует репозиторий во временный каталог, ставит зависимости (определяет pnpm, yarn или npm и ставит без install-скриптов), копирует сгенерированные тесты и запускает tsc --noEmit и ESLint. Если есть ошибки, они возвращаются модели с просьбой исправить, и валидация запускается заново — максимум три попытки. После третьей неудачной попытки сессия идёт дальше с лучшим полученным результатом, а человек видит, что осталось поправить. Валидацию можно и пропустить.

Важно прямо сказать, чего эта валидация не делает: она не запускает тесты. Она проверяет, что тест компилируется и проходит правила линтера, то есть ловит выдуманные импорты, неверные типы и несуществующие функции. Она не проверяет, верны ли сами проверки. Настоящая проверка — первый прогон CI на pull request.

После валидации все тесты видны в редакторе в браузере. Их можно читать, править вручную и перегенерировать отдельные файлы, не трогая остальные. Коммит создаёт от ветки по умолчанию ветку ai/test-gen- с меткой времени, кладёт все файлы в один коммит и — если отмечено — открывает pull request со списком сгенерированных файлов. Сессия переживает закрытие браузера: к ней можно вернуться и продолжить с того места, где она остановилась.

Где генерация тестов по коду ломается

Самая частая проблема, которую мы описываем в документации продукта, — алиасы путей в монорепозиториях. Система вычисляет относительные импорты, а проект использует алиасы вроде @app/shared из секции paths в tsconfig.json. Тест логически верен, но импорт приходится поправить вручную на шаге ревью.

Вторая проблема — галлюцинации Галлюцинация — это ответ ИИ, который звучит убедительно, но неправдив: модель заполняет пробел догадкой вместо того, чтобы признать, что не знает. Полное определение → во вспомогательных объектах. Модель иногда придумывает поле интерфейса или сигнатуру функции, которой нет, особенно в моках. Второй проход модели и tsc ловят большую часть таких случаев, но со сложными типами что-то может проскочить.

Третья — конфигурации сборки, которые изолированный клон не воспроизведёт: собственные загрузчики Webpack, шаги кодогенерации, зависимости, которым нужны install-скрипты. Тогда валидация падает независимо от качества теста, и остаётся её пропустить, а поправить всё после коммита.

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

Пятая — охват. Лучшие результаты дают TypeScript и JavaScript с Jest или Vitest, потому что для них сильнее всего развиты разрешение импортов и валидация через tsc и ESLint. Мастер проверяли также с Mocha и Playwright, pytest, JUnit, стандартным пакетом testing в Go и cargo test в Rust, но там шаг валидации проверяет меньше.

К этому добавляются время и стоимость. Каждый файл — это два-три вызова модели. По нашей документации, на десять одобренных пунктов уходит 3–5 минут, а типичная сессия на пять файлов расходует примерно 30–60 тысяч токенов в зависимости от сложности кода. Расход токенов виден в деталях сессии.

E2E-тесты по описанию: чек-листы и Playwright

Не каждый тест разумно выводить из кода. Сценарий «пользователь регистрируется с уже занятым адресом почты» лучше описать словами и проверить на работающем приложении. Для этого в Testing AI есть второй путь.

Агент генерирует чек-лист по адресу приложения, адресу репозитория или описанию: от 10 до 25 сценариев, у каждого заголовок, описание, ожидаемое поведение и приоритет. Чек-лист проходит собственную валидацию и до двух раундов исправлений. Из каждого пункта можно сгенерировать тест на Playwright с доступными селекторами. Ревьюер на более быстрой модели проверяет синтаксис, использование API Playwright, импорты, отсутствие жёстко прописанных адресов и осмысленные проверки, максимум за три раунда исправлений.

Запуск чек-листа выполняет тест каждого пункта по очереди на указанном адресе приложения. Результат каждого пункта — статус, время, лог и скриншоты — появляется по ходу выполнения. Чек-листы можно экспортировать и импортировать в JSON, так что их можно хранить в репозитории рядом с кодом.

Как выглядят запуски: пайплайн, Temporal, параллельность

Сгенерировать тесты — половина работы; вторая половина — регулярно их запускать. В Testing AI пайплайн Пайплайн — это заранее заданная последовательность шагов обработки: в отличие от агента он не выбирает порядок, а всегда выполняет один и тот же. Полное определение → — это список шагов, а каждый запуск — workflow в Temporal. Сначала репозиторий клонируется на указанном коммите. Затем юнит-тесты, интеграционные тесты, линтер, SAST и аудит зависимостей идут параллельно, а E2E (включая Playwright), нагрузочные тесты (включая k6), DAST и замер покрытия — последовательно после них. E2E-тесты пропускаются, если юнит-тесты не прошли: нет смысла прокликивать приложение, логика которого уже сломана.

У каждой активности свой таймаут и своя политика повторов в Temporal, так что кратковременная сетевая ошибка при клонировании не обрывает весь запуск, а падение одного шага не останавливает остальные. SAST использует Semgrep, если он доступен, DAST — OWASP ZAP, аудит зависимостей — npm, yarn или pnpm audit, pip-audit или govulncheck в зависимости от проекта. Прогресс шагов приходит в дашборд вживую через Server-Sent Events, а скриншоты, записи и отчёты о покрытии — в хранилище артефактов.

Запуски по расписанию: как обстоят дела сейчас

Поисковый вопрос обычно звучит как «генерирует тесты и планирует запуски», поэтому отвечаем прямо. В модели пайплайна четыре триггера: push, pull request, расписание с cron-выражением и ручной запуск. Вебхуки от GitHub, GitLab и Bitbucket принимаются и проверяются по подписи. Однако в текущей версии автоматический старт запусков по cron-выражению и по вебхукам ещё не подключён: конфигурацию сохранить можно, но запуск стартует из дашборда, через API (POST /test-runs) или из чата, у которого есть инструмент для запуска пайплайна.

Если ночные прогоны нужны уже сейчас, самый простой путь — задача по расписанию в вашем CI, которая вызывает этот API. Сам прогон, отчётность и анализ результатов работают одинаково, что бы его ни запустило.

Что происходит после запуска: нестабильные тесты, баги, покрытие

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

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

Testing AI рядом с инструментами, которые называют AI-ассистенты

В сентябре 2026 года мы задали ChatGPT этот вопрос по-английски и по-русски: есть ли AI-инструменты, которые сами пишут тест-кейсы по исходному коду проекта и планируют их запуски. По-английски он назвал TestSprite, Qodo и ContextQA, по-русски — Qodo, Diffblue и EvoSuite. Это хороший срез рынка, потому что эти инструменты относятся к разным группам из первого раздела. Сравнение ниже основано на публичных описаниях производителей и сопоставляет категории, а не качество.

EvoSuite и Diffblue Cover — инструменты для Java, сосредоточенные на юнит-тестах, и ни один из них не построен на большой языковой модели: EvoSuite генерирует тесты поиском, а Diffblue описывает свой движок как обучение с подкреплением. Qodo представляет себя как платформу AI-ревью кода и работает в IDE и на pull request; генерация тестов входит в его плагин для IDE. TestSprite и ContextQA начинают с работающего приложения и end-to-end сценариев; на сайте TestSprite указаны запуски по расписанию, на сайте ContextQA — интеграция с Jenkins и GitHub Actions.

Testing AI объединяет в одном месте генерацию тестов по коду, генерацию E2E-сценариев и выполнение пайплайнов, а результат генерации отдаёт как pull request. Он не заменит специализированный инструмент, если нужно массово покрыть старый код на Java. Он имеет смысл, когда команде нужна одна панель для генерации, запуска и анализа результатов.

Как выбрать подход для своего проекта

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

В любом случае действуют одни и те же правила: начинайте с узкой области, ревьюте сгенерированный код как любой другой и оценивайте результат по прогону в CI, а не по числу сгенерированных файлов. В мастере Testing AI это на практике значит: задайте область фокуса, для начала одобрите несколько пунктов с высоким приоритетом, не пропускайте валидацию без причины и всегда создавайте pull request.

Что внутри: агенты, модели, инфраструктура

Агенты Testing AI — это графы состояний в LangGraph LangGraph — это инструмент для разработчиков, который позволяет строить ИИ-агентов с многошаговыми сценариями и ветвлением, а не с одним разовым ответом. Полное определение →. У генератора тестов есть узлы анализа кода, генерации, валидации, доработки и форматирования; у агента чек-листов и агента Playwright-тестов похожий цикл с ограничением числа раундов доработки. По умолчанию предложение и генерация тестов используют модель o3, а анализ профиля проекта, валидация и быстрые задачи — gpt-4.1-mini; обе модели задаются переменными окружения. Бэкенд — микросервисы на NestJS с отдельной базой PostgreSQL на каждый сервис, выполнение тестов — worker Temporal, дашборд — Next.js.

Подробнее о том, как агенты берут на себя рутину в QA, мы пишем в статье Как AI-агенты берут на себя рутину в QA. Описание продукта — на странице Testing AI Assistant, исходный код — на GitHub.