Генерация автотестов и локаторов нейросетью на legacy-проекте: практический опыт

Автор продолжает практическую серию об автогенерации тестов: в новой статье она разбирает, как именно генерировала автотесты и локаторы для большого legacy-проекта, сколько на это ушло времени, где модель ошибалась и стоило ли оно того.

Что показала предыдущая часть серии

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

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

Где обычно спотыкается генерация локаторов

Локаторы — это, пожалуй, самое уязвимое место автогенерации UI-тестов: они завязаны на конкретную разметку страницы, которая в legacy-проектах часто нестабильна, непоследовательна и не документирована. Модель, генерирующая локаторы без глубокого понимания реальной структуры DOM конкретного экрана, рискует предложить хрупкие селекторы — те, что легко ломаются при малейшем изменении вёрстки, или дублируют уже существующие в проекте локаторы вместо переиспользования готовых.

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

• Формат — вторая статья серии о генерации автотестов и локаторов с ИИ
• Условие из первой статьи — README с описанием архитектуры фреймворка обязателен для legacy-проекта
• Фокус новой статьи — конкретный процесс, затраченное время и типичные ошибки модели
• Объект тестирования — большой legacy-проект

Что это значит

Опыт подобных серий статей показывает: генерация автотестов с помощью ИИ на практике не сводится к простому «попросил — получил рабочий код». Она требует подготовительной работы с контекстом проекта и трезвой оценки, в каких сценариях экономия времени реальна, а в каких она компенсируется ручным ревью и доработкой сгенерированного кода.