В последнее время вокруг систем ИИ, генерирующих тесты, активно развивается дискуссия, причем как в профессиональной, так и в академической среде. С одной стороны, такие системы делают ровно то, для чего задуманы ИИ-агенты: выполняют работу, которую мало кто любит делать, экономят массу времени и сил. С другой — порой выдают непредсказуемый результат: удаляют или корректируют тест-кейсы, игнорируют пограничные сценарии.
Мы решили посмотреть, какие мнения есть относительно генеративных тестов в ИТ-индустрии, и что говорит на их счет наука — разобрали свежие исследования по теме. А в конце статьи сделали подборку из открытых инструментов, которые помогут оценить возможности пары «нейросеть + юнит-тесты» самостоятельно.
Юнит-тесты + ИИ: что об этой связке думают в индустрии
Многие разработчики не любят писать тесты — и высказываются по этому поводу довольно категорично. Еще в 2014 году известный ученый в области программной инженерии и эксперт по языку C++ Джеймс Коплиен опубликовал статью, в которой называл юнит-тесты «бесполезной тратой [времени и сил]». Прохладное отношение разработчиков к модульным тестам обсуждали даже здесь на Хабре. Сегодня настроения в индустрии остаются похожими: по некоторым оценкам, от 40 до 50% разработчиков предпочли бы не писать тесты вовсе.
Один из вариантов решения проблемы — генерировать юнит-тесты с помощью ИИ. Быстро, удобно: нейросеть за считаные минуты покрывает ими весь код. Но отношение к такой практике среди разработчиков, мягко говоря, неоднозначное. С одной стороны, модульные тесты, сгенерированные с помощью ИИ-агентов, конечно, экономят время. Для крупных компаний эта экономия может достигать сотен человеко-часов. Например, в Goldman Sachs использовали инструмент Diffblue Cover, который пишет юнит-тесты на Java. С его помощью инженеры за сутки оформили 3,2 тыс. тестов для бэкенд-приложения из 15 тыс. строк кода — по оценкам компании, без системы ИИ на такую задачу ушли бы 268 рабочих дней.
С другой стороны, генерация модульных тестов имеет недостатки. Часть из них проявляется сразу, часть — по мере сопровождения проекта, многие носят системный характер и не зависят от используемых моделей. Обычно недовольство касается того, что ИИ-агенты:
Могут закреплять баги в коде как «корректное поведение». Если тесты пишутся на основе готового кода, модель может проверять, что функция делает сейчас, а не то, что ей положено делать. Разработчик из GitHub и Ph.D. в области компьютерных наук Дэвид Адамо-младший в своем блоге называет это «самосбывающимся пророчеством»: агент смотрит на сигнатуры и имена переменных, угадывает ветвления и подгоняет тест-кейсы под текущий результат.
Могут пропускать пограничные сценарии. Как следствие, сгенерированные тесты могут покрывать только типовые значения и игнорировать кейсы с переполнением, гонками, не учитывать редкие ошибки и таймауты. Кроме того, языковые модели склонны к галлюцинациям: обращаются к несуществующим методам, полям и сигнатурам, что ведет к некомпилируемым тестам.
Могут «подгонять» код тестов под текущую реализацию программы. За нейросетями замечена склонность решать задачу любой ценой — и в разработке это проявляется особенно наглядно. Столкнувшись с падающим тестом или сложным рефакторингом, агенты нередко удаляют тестовые файлы или вырезают отдельные проверки. В итоге сборка проходит без ошибок, но проблема в коде остается — и если разработчик привык доверять агенту, узнать о ней он может уже в продакшене.
Этот кейс куда более распространен, чем может показаться на первый взгляд. Джин Ким, автор книги «Проект "Феникс"» и экс-разработчик Google, рассказывал, как сталкивался с нейросетями, которые втихую правили «падающие» тесты, лишь бы они прошли — однажды агент удалил 80% тест-кейсов из набора. А в прошлогоднем интервью для площадки The Pragmatic Engineer создатель методологий разработки XP и TDD Кент Бек жаловался, что не может отучить ИИ-агентов удалять отдельные тестовые сценарии ради успешного прогона.
Что говорят исследования
Тема юнит-тестов и их генерации привлекает и внимание исследователей. За последние годы вышло большое количество научных работ, авторы которых стремятся систематизировать преимущества и недостатки подобного подхода — и, в отличие от Джина Кима и Кента Бека, они высказываются не так категорично. Вот, к каким результатам приходят в недавних публикациях:
Генеративные тесты действительно могут закреплять баги в коде, но масштаб проблемы не так уж велик: исследование Университета Торонто
Летом этого года группа исследователей из Университета Торонто представила работу, в которой решила оценить, насколько сильно качество кода и наличие в нем ошибок влияет на способность ИИ-агентов генерировать корректные тесты. Для этого они взяли бенчмарк Defects4J, содержащий сотни реальных ошибок из крупных проектов на языке Java. В наборе они представлены парами: версия кода с дефектом и версия, исправленная разработчиками.
Одиннадцати моделям от Google, OpenAI, Anthropic, xAI, DeepSeek и Alibaba показывали ошибочный вариант метода и просили написать юнит-тесты, а затем прогоняли их на сломанной и на корректной версиях. Если тест проходил на коде с дефектом, но падал на исправленном, значит, модель посчитала баг за ожидаемое поведение, а если наоборот — тест свою работу выполнял и считался корректным. Оказалось, что модели закрепляли ошибку в 3,84% тестов.
Хотя авторам исследования удалось немного сократить и эту цифру. Они предложили разорвать связь между тестом и реализацией: модель просили описать, что должен делать конкретный метод, и оформить это описание в docstring, а затем исходный код убирали из промпта. Когда модель писала юнит-тест на основе описания docstring, доля тестов, закрепляющих баг, снизилась с 3,84 до 2,69%.
В сгенерированных тестах наблюдается эффект «test smells» : результаты анализа 20 тыс. тестовых наборов
Существует понятие code smells — недостатки в программе, которые ухудшают ее читаемость и поддерживаемость. Это могут быть раздутые методы на сотни строк, дублирование, классы, которые делают все и сразу. По аналогии применяют термин test smells — признаки глубоких проблем в архитектуре или логике тестов. Недавно исследователи из Люксембурга, Китая, Сингапура и Турции задались вопросом: насколько ярко выражены подобные паттерны в тестах, генерируемых нейросетями, и насколько сильно их проявление зависит от промпта.
Команда проанализировала больше 20 тыс. тестовых наборов, написанных четырьмя ИИ-системами на базе нескольких Java-бенчмарков. Чтобы выявить проблемы, специалисты использовали инструменты TsDetect и JNose. В ходе эксперимента они также проверили, как на количество этих проблем влияют характеристики кода (объем, цикломатическая сложность, связанность классов) и параметры генерации (размер модели, длина контекстного окна, настройки семплирования).
Выяснилось, что чем крупнее проект, тем больше в тестах избыточных и поверхностных проверок. Что касается конкретных ошибок, то в сгенерированных тестовых наборах чаще всего встречалась проблема с assertion roulette, когда в одном тестовом методе находится много проверок assert без текстовых описаний. Так, если тест «падает», становится трудно понять, какая именно проверка не прошла.
Также специалисты отметили, что по какой-то причине агенты почти не покрывают тестами обработку исключений: у классического генератора EvoSuite (он использует эволюционные алгоритмы) этот показатель доходит до 93%, у нейросетей же держится в пределах 7–23%. Но даже если обойти эти моменты с помощью промптов, могут появляться и другие проблемы — например, дублирование проверок. В итоге исследователи пришли к выводу, что на данном этапе к сгенерированным тестам стоит относиться как к черновикам, требующим правок со стороны разработчика.
Несколько более оптимистичны швейцарские ученые — по их мнению, чтобы писать тесты, не всегда нужен даже узкоспециализированный агент (хотя и в этом исследовании результаты работы ИИ оказались довольно скромными):
ИИ-агенты, заточенные под написание кода, могут писать качественные тесты — исследование ETH Zurich
Специалисты из Швейцарской высшей технической школы Цюриха и компании по разработке ПО LogicStar проверили, насколько хорошо ИИ-агенты превращают оформленный GitHub issue в готовый тест-кейс. Для этого они собрали собственный Python-бенчмарк SWT-Bench почти из двух тысяч задач, построенных на основе 90 тыс. пул-реквестов из 12 популярных open source-репозиториев на GitHub.
Далее агентов, в первую очередь предназначенных для исправления ошибок в коде (SWE-agent, Aider и AutoCodeRover), попросили написать юнит-тесты, покрывающие проблему, просто изменив формулировку в промпте. Критерий успеха был простым: сгенерированный тест должен падать на исходном коде и проходить после применения эталонного исправления. Специалисты пришли к выводу, что системы ИИ, которые самостоятельно находят проблемные места в коде и пишут патчи с исправлениями, могут превосходить по эффективности узкоспециализированных агентов для генерации юнит-тестов — таких как LIBRO. LIBRO справился с 14,1% задач, а обычный SWE-agent — с 15,9%.
Какой подход выбрали мы в Далее
Итак, по мнению ученых, работать с генеративными тестами сложно, но можно. Справедливости ради, многие разработчики (как, например, программист и писатель Марк Земан) тоже не призывают полностью отказаться от ИИ-агентов для генерации тестов и предлагают приемы, которые могут улучшить результат:
Можно развести роли по разным агентам: один пишет код, а второй, который никогда не «видел» исходники, — готовит тесты. Суть подхода заключается в том, чтобы системы ИИ не делили одно рабочее пространство и не подтверждали сделанные в коде ошибки.
Использовать мутационное тестирование: внести в код намеренный баг, похожий на типичную ошибку, и посмотреть, поймает ли его сгенерированный набор тестов.
Мы в Далее тоже относимся к генеративным тестам с должной осмотрительностью — но не отказываемся от них полностью:
В настоящее время мы находимся на этапе пилотного внедрения: ИИ используется при написании тест-кейсов, но в ограниченной роли — как инструмент оформления и как «второй взгляд», способный предложить негативные сценарии, которые можно упустить при ручной проработке.
Влад Голодников
руководитель отдела QA в Далее
Наш подход. Мы задаём агенту контекст проекта и суть проверяемой функциональности, а также логику, которую закладываем сами. На выходе получаем корректно оформленный тест-кейс, соответствующий заданной логике [формализованного регламента для проверки генеративных тестов у нас нет, проверка встроена в общий процесс ревью и не выделяется в самостоятельную процедуру]. Полностью автоматическая генерация кейсов без предварительного погружения модели в контекст проекта показывает посредственное качество, поэтому мы её не применяем.
Отдельно стоит отметить работу с чек-листами: здесь ИИ показывает себя достаточно хорошо и, как правило, покрывает большую часть необходимых и значимых проверок.
Плюсы:
Быстрое и аккуратное оформление тест-кейсов по заданной логике — экономия времени на рутинной части.
Генерация негативных сценариев, которые могут быть упущены при ручной проработке.
Высокое качество формируемых чек-листов с покрытием основных проверок.
Минусы:
Качество автоматически сгенерированных кейсов заметно падает без достаточного контекста проекта.
Верификация и правка результата в ряде случаев занимает больше времени, чем самостоятельное написание кейса с нуля.
Сохраняется необходимость экспертного контроля: результат нельзя принимать без ревью.
Так что на текущий момент ИИ рассматривается нами не как замена ручному проектированию тестов, а как вспомогательный инструмент для ускорения оформления и расширения покрытия сценариев. И учитывая, что текстовый контент сейчас все чаще создается с использованием ИИ (и код — как частный случай — не исключение), дискуссия о том, применять или не применять ИИ-агентов для его генерации уже несостоятельна — вопрос не в том, кто автор, а в том, насколько хорош результат:
Пытаться выявлять и целенаправленно устранять признаки генеративного происхождения материала, будь то новость, пост или юнит-тест, на мой взгляд, не имеет практического смысла — это борьба со следствием, а не с сутью.
В обозримой перспективе генеративный контент в самом широком смысле станет отраслевой нормой, а полностью ручное написание перейдёт в категорию скорее ремесленного или авторского подхода, чем повседневной практики.
Соответственно, фокус проверки, с моей точки зрения, должен смещаться с вопроса «как это было написано» на вопрос «насколько это корректно, полно и применимо». Оценивать имеет смысл содержательное качество — покрытие, корректность логики, соответствие требованиям, а не происхождение формулировок.
Влад Голодников
руководитель отдела QA в Далее
На чем потестить юнит-тесты: открытые ИИ-агенты
Для тех, кто хочет составить собственное мнение об эффективности генеративных тестов, мы собрали подборку профильных инструментов.
Test Generator Agent — агент-полиглот от Microsoft для генерации юнит-тестов. Он работает с C#, Python, Go, TypeScript, Java, Rust и другими языками. Инструмент не просто пишет тесты, а проверяет их состоятельность — качество утверждений (assertions) и покрытие запрошенных сценариев. В первую очередь он изучает репозиторий: ищет код без тестового покрытия, определяет язык и разбирает уже существующие тесты, чтобы понять, где они лежат и как должны выглядеть — только после этого он планирует, готовит и проверяет собственные.
Разработчики провели несколько экспериментов, в том числе использовали задачи по написанию юнит-тестов из набора SWE Atlas, который считается довольно сложным. Специализированный агент прошел на четыре задачи больше, чем стоковый Copilot на той же модели и с теми же промптами.
Агент, скиллы и языковые расширения открыты под MIT и лежат в репозитории dotnet/skills. Чтобы начать работу, достаточно выбрать code-testing-generator из списка агентов и прописать простой промпт: Generate unit tests.
Qodo Cover — инструмент для автоматической генерации тестов, который может работать как в GitHub CI, так и локально в виде CLI-утилиты. Исходники открыты под лицензией AGPL 3.0. Система состоит из четырех компонентов:
Test Runner — запускает скрипты тестового набора и собирает отчеты о покрытии кода тестами.
Coverage Parser — проверяет, что новые тесты не бесполезны, а покрытие растет.
Prompt Builder — собирает данные из кодовой базы и формирует промпт для языковой модели.
AI Caller — обращается к модели и получает сгенерированные тесты.
Также Qodo Cover прогоняет все тесты по пять раз, чтобы выявить «мигающие», которые то проходят, то падают, при неизменном коде.
К сожалению, при всех достоинствах проекта, у него есть минус: разработчики не планируют поддерживать репозиторий, поэтому желающим продолжить разработку или использовать код в своих проектах, предлагают его форкнуть.
Наконец, в качестве бонуса, — чисто детерминированный статический анализатор для поиска «запахов» в тестах Java-проектов, под названием Test Smell Detector. Он вырос из академического проекта в Рочестерском технологическом институте. Команда отмечала, что открытых детекторов с широким охватом типов и поддержкой CI не хватало. Тогда специалисты решили сделать свой собственный и передать его в open source под лицензией GPL 3.0. И именно его использовали ученые из приведенного выше исследования про test smells.
Какой бы инструмент вы ни выбрали, основную ценность в итоговый результат будет привносить человек и его квалификация:
На горизонте ближайших пары лет, с учётом текущих темпов развития ИИ, я ожидаю, что значительная часть задач разработки и тестирования будет закрываться средствами ИИ. Появление у моделей возможностей работы с визуальным контекстом (vision) уже сегодня заметно повышает их прикладную ценность — ИИ становится действительно полезным помощником, а не только генератором текста.
При этом ключевым фактором остаётся не сам инструмент, а квалификация специалиста, который им управляет. Поэтому в первую очередь я бы рекомендовал уделять внимание не конкретным продуктам, а фундаментальной базе:
Архитектура систем — понимание того, как устроено приложение, позволяет корректно формулировать задачу и оценивать адекватность полученного результата;
Алгоритмы и основы разработки — без этого невозможно объективно верифицировать то, что предлагает модель;
Методология тестирования — понимание, что и почему проверяется, остаётся зоной ответственности человека.
Эта база даёт возможность точно объяснить ИИ, что именно требуется сделать, каким образом и что является критически важным в конкретном контексте, а также самостоятельно оценить качество результата.
Что касается инструментов — сейчас имеет смысл в рабочем режиме осваивать ИИ-ассистентов (как в связке с IDE, так и в формате агентов), включая работу с визуальным контекстом, и вырабатывать навык качественной постановки задачи. Но рассматривать их стоит именно как усилитель собственной экспертизы: чем глубже понимание того, как система разрабатывалась и тестировалась, тем выше отдача от использования ИИ.
Влад Голодников
руководитель отдела QA в Далее
Уже используете генеративные тесты — или считаете, что пока ИИ-агентам эта задача не по зубам? Поделитесь вашим опытом в комментариях.