Контроль качества

impact-analysis

Kotlin CLI, который по diff'у вычисляет, какие UI-тесты реально нужно прогнать.

Что это

Инструмент статического анализа Android-кодовой базы. Строит граф связей «экран → шаг → тест» и по изменённым файлам определяет минимальный набор затронутых тестов — в формате, который понимает раннер.

Пять команд CLI, каждая — отдельный сданный этап: поиск деклараций экранов с обогащением UI-метаданными, сканирование шагов с устойчивым идентификатором, сканирование тестов и связывание их со шагами, сборка графа, анализ изменений. Собирается в runnable fat jar и запускается как production-CLI.

Задача, которую решает

Полный прогон UI-тестов на Android — дорогая и долгая операция, в CI она становится узким местом. Инструмент отвечает на вопрос «какие тесты реально задеты этим изменением» и позволяет гонять только их.

Что демонстрирует

• Методология, а не везение: сначала исследование реальной кодовой базы отдельным этапом, затем 10 шагов, у каждого — измеримый критерий приёмки, зафиксированный в README.
• Декомпозицию под агента: задача разбита так, чтобы агент не терялся на большом чужом коде; уточняющие подэтапы появлялись как реакция на факты, а не придумывались заранее.
• Честную работу с краевыми случаями: известные исключения зафиксированы явно и осознанно отложены, а не замаскированы зелёным прогоном.
• Ориентацию на эффект: цель не «инструмент написан», а сокращение времени прогона тестов в CI.

Факты

Стек и подход

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

Теги

След ИИ-процесса

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