Умная регрессия — запускайте только тесты, на которые влияет изменение

Умная регрессия анализирует файлы, изменённые в коммите, и сообщает,
какие тест-кейсы действительно нужно прогнать — вместо перезапуска всего
набора на каждый push. Это анализ влияния тестов (Test Impact
Analysis) для CI: вы отправляете список изменённых файлов, Mockarty
возвращает затронутый набор тестов плюс вердикт безопасности, а ваш
пайплайн прогоняет только это подмножество.

Это детерминированно — без ИИ, без обучения, без модели. Отбор —
прямое сопоставление изменённых файлов с записанным расположением
исходника каждого теста плюс два «всегда-прогонять» бакета безопасности.

Что попадает в отбор

Отобранный набор — это объединение до четырёх бакетов:

Профили риска

Выберите, насколько агрессивно сужать набор:

• conservative (по умолчанию) — все четыре бакета, включая
  несопоставимые тесты. Безопаснее всего; никогда не пропускает тест,
  о котором анализ не может судить.
• standard — затронутые ∪ ранее-упавшие ∪ ни-разу-не-прогонявшиеся.
• fast — только затронутые по пути. Минимальный набор, выше риск;
  используйте, когда у тестов полные исходные ссылки.

Защита от ошибок (fail-safe)

Если об изменении нельзя судить — нет изменённых файлов, нет покрытия
исходными ссылками или нет тест-кейсов — вердикт inconclusive
(неопределённо), и следует прогнать полный план. Умная регрессия
никогда не пропускает тест молча при неопределённости.

Использование в CI (CLI)

CLI собирает diff и запрашивает сервер:

mockarty-cli util ci impact \
  --server https://mockarty.example.com \
  --base origin/main --head HEAD \
  --namespace my-team \
  --risk conservative \
  --allure-out testplan.json

Вывод:

✓ 12 test case(s) selected from 7 changed file(s)
  risk=conservative buckets: affected-by-path=4 previously-failed=2 never-run=5 unmappable=1 (union=12)
  wrote Allure testplan (12 tests) → testplan.json

--allure-out пишет стандартный файл тест-плана. Укажите его вашему
раннеру (ALLURE_TESTPLAN_PATH=testplan.json) — и он прогонит только
отобранное подмножество. Когда вердикт неопределённый, файл не
пишется — пайплайн должен прогнать полный план.

SDK Mockarty для Go, Python и Java читают этот файл «из коробки» и, если он
пуст или битый, отказываются от прогона, а не откатываются молча к полному.
Точное поведение и формы селекторов для каждого языка — в разделе
Выборочный прогон (тест-планы).

Собрать Mockarty Test Plan

Вместо экспорта файла для внешнего раннера можно попросить Mockarty
собрать Test Plan ровно из отобранных кейсов и (опционально) запустить его:

mockarty-cli util ci impact \
  --base origin/main --head HEAD --namespace my-team \
  --assemble-plan \
  --plan-name "Регресс PR #482" \
  --run

--assemble-plan создаёт план и печатает его id (advisory — человек может
посмотреть и запустить из UI). Добавьте --run, чтобы сразу стартовать
оркестрированный прогон и получить id прогона. Когда вердикт неопределённый,
план не собирается (прогоните полный план).

GitHub Actions

name: smart-regression
on: pull_request
jobs:
  impact:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0          # полная история, чтобы был доступен base ref
      - name: Вычислить затронутые тесты
        env:
          MOCKARTY_SERVER: ${{ secrets.MOCKARTY_SERVER }}
          MOCKARTY_API_TOKEN: ${{ secrets.MOCKARTY_API_TOKEN }}
        run: |
          mockarty-cli util ci impact \
            --base "origin/${{ github.base_ref }}" --head HEAD \
            --namespace my-team --risk conservative \
            --allure-out testplan.json
      - name: Прогнать отобранные тесты
        env:
          ALLURE_TESTPLAN_PATH: testplan.json
        run: ./run-tests.sh    # ваша существующая команда тестов

Влияние на потребителей (не сломало ли изменение сервис ниже по цепочке?)

Если изменение затрагивает сервис, для которого вы публикуете контракт,
передайте id его записи в реестре — и Умная регрессия дополнительно
проверит, не сломает ли изменение какого-либо потребителя этого
сервиса:

mockarty-cli util ci impact --base origin/main --head HEAD \
  --provider-entry <registry-entry-id> \
  --fail-on-consumer-break

С --fail-on-consumer-break команда завершится с ненулевым кодом, если
потребитель сломается, останавливая пайплайн. Без флага проверка
рекомендательная (сообщается, но не блокирует).

API

POST /api/v1/ci/impact?namespace=my-team
{
  "changedFiles": ["src/api/user.go", "src/login.py"],
  "base": "origin/main", "head": "HEAD",
  "risk": "conservative",
  "providerRegistryEntryIds": ["<id>"],
  "assemblePlan": true,
  "runAfterAssemble": false,
  "planName": "Регресс PR #482"
}

Ответ содержит selectedCaseIds, selectedCases (id + selector),
по-бакетный buckets, вердикт inconclusive + reason и опциональный
блок consumerImpact. Когда задан assemblePlan (и вердикт определённый),
ответ также несёт assembledPlanId (и assembledRunId, если задан
runAfterAssemble).

Для ИИ-агентов

Тот же анализ доступен агентской сети как инструмент
analyze_regression_impact (группа Test Plans). Автономный агент,
рассуждающий «что мне перепрогнать после этого изменения?», получает тот
же отбор, fail-safe-вердикт и влияние на потребителей, что человек или
CI-пайплайн.

Примечания

• Отбор ограничен вашим пространством; вы никогда не видите тесты другой
  команды.
• Точность зависит от полноты исходных ссылок тестов — тесты,
  обнаруженные из вашего кода или импортированные с картой расположения,
  сопоставляются точно; тесты без неё попадают в безопасный бакет
  «несопоставимые» при профиле conservative.