testgraph

testgraph — это селектор тестов уровня пользовательских сценариев (journey-level). На основе git diff он определяет, какие пользовательские потоки могли быть нарушены изменением и в каком порядке их следует протестировать, возвращая короткий ранжированный список вместо указания перезапускать всё. Он намеренно не управляет браузерами, не генерирует тесты и не обладает функцией самовосстановления; его задача — уровень над существующими драйверами, а именно определение того, что стоит тестировать. Как это работает Реестр сценариев (journey registry) содержит имена каждого пользовательского пути и его входные символы, такие как обработчики маршрутов или циклы планировщика. Модуль propose создает проект реестра для нового репозитория, сканируя декораторы маршрутов Python и соглашения Next.js по индексу, помечая его как неодобренный (approved false) до проверки человеком, чтобы неодобренный реестр работал заметно, а не незаметно. Для diff-файла testgraph сопоставляет измененные диапазоны строк с владеющими ими символами (seeds); рекурсивно проходит по графу ребер CodeGraph в обратном направлении ко всем символам, зависящим от seed (impacted set); и сообщает о сценариях, чьи входные символы входят в этот набор, ранжируя их по входящему потоку (fan-in), при этом каждый имеет уровень уверенности (confidence) самого сильного пути ребер. Уверенность — это максимум по путям от минимума по ребрам, поэтому цепочка надежна лишь настолько, насколько надежно ее самое слабое звено, в то время как одного надежного маршрута достаточно. Сценарий, достигнутый только через слабые или синтезированные ребра, помечается для ручной проверки, а не принимается на веру, и никогда не удаляется из выборки. Инструмент ориентирован прежде всего на полноту (recall-first): он предпочитает избыточный выбор молчаливому пропуску сценария, на который изменение действительно повлияло. Перед ответом защитный механизм целостности (integrity guard) отказывается работать с поврежденным или устаревшим индексом CodeGraph, так как неверный граф дает уверенно неправильный ответ. Разрешение реестра работает по принципу «первого совпадения»: сначала проверяется переменная окружения, затем директория .testgraph/journeys внутри репозитория (рекомендуемое место), затем директория journeys рядом с пакетом в чекауте проекта. Реестр сопоставляется по его самостоятельно объявленной цели, а не по имени файла; копирование реестра из другого проекта без редактирования запрещено. Предварительные требования и установка Python 3.11 или новее (только стандартная библиотека, без сторонних зависимостей); git для ввода diff; и целевой репозиторий с индексом CodeGraph, созданным с помощью codegraph init. Установка из PyPI: pip install testgraph. Wheel содержит только пакет, в то время как измерительный комплекс и реестры для внутреннего тестирования (dogfood) находятся в репозитории. CLI и MCP Точки входа командной строки включают select (вывод в человекочитаемом формате или JSON для CI-гейта или другого агента); export (записывает статическую карту сценариев для агента перед коммитом); propose; record; и режим summary. MCP stdio сервер предоставляет два инструмента, testgraph_impact и testgraph_journeys, и регистрируется для каждого репозитория. Он использует только stdlib и лениво импортирует модули анализа, поэтому простой сервер не загружает sqlite3, не держит соединение с базой данных и не хранит индекс в памяти. В README указано, что RSS составил 15.2 МБ после полного рукопожатия, против 62–69 МБ для типичного сервера Python MCP SDK. Связки и реестр (ledger) hooks/install.sh устанавливает pre-push хук в каждый репозиторий с одобренным реестром, чтобы при каждом пуше выводились сценарии, которые могли быть нарушены. Хук сначала запускает codegraph sync, так как seeds берутся из диапазонов строк, и индекс, созданный до перемещения кода, сопоставил бы diff с устаревшими интервалами; если байты измененного файла все еще не совпадают с индексированной копией, точность ответа снижается и файл указывается в выводе. Хук никогда не прерывает пуш (всегда exit 0) и может быть отключен через git config или удален с флагом uninstall. Каждый запуск добавляет строку выбора в JSONL-реестр; команда record записывает вторую часть — результаты выполнения сценария. Объединение этих данных по репозиторию и коммиту позволяет подсчитать случаи, когда сценарий завершился сбоем, но не был указан в выборке (silent under-selection). Статус Проект описывается как фаза-1 (spike) с путями, взвешенными по уверенности, проверенная на одном внутреннем целевом объекте: полнота (recall) 1.00 на пяти размеченных вручную коммитах при средней точности 0.68, и 1.00 на двадцати точках мутаций, проверенных независимым AST-оракулом; защитный механизм целостности протестирован, схема зафиксирована. Область охвата — этот единственный объект, анализ файлов бэкенда и фронтенда со сценариями, зарегистрированными на точках входа бэкенда. В README также отмечено, что последующие измерения на двух репозиториях без реестра опровергли прежние заявления об экономии: при 23 сценариях один репозиторий показал 0 сценариев для 38 коммитов и 23 для 2 коммитов, а при 207 сценариях другой избежал только 54.1% запусков (после исключения коммитов, не затрагивающих зарегистрированные поверхности). Таким образом, цифры выборки следует рассматривать как нижний порог связанности, а не как гарантию экономии. Те же измерения подтвердили ранжирование: ложноположительный выбор всего реестра был помечен для ручной проверки с уверенностью 0.3, в то время как реальный большой радиус поражения был определен чисто с уверенностью 0.9.