# Аналитика тестов Bazel {#bazel-test-insights}

> [!IMPORTANT]
> **Требования**
>
> - Рабочее пространство Bazel, подключённое через `tuist bazel setup`, как описано в <.localized_link href="/guides/get-started/bazel-project">Начало работы с проектом Bazel</.localized_link>.

`tuist bazel setup` настраивает отчётность по отдельным тест-кейсам в `.bazelrc.tuist`, поэтому обычный `bazel test` отправляет данные об отдельных тест-кейсах на те же дашборды, что и другие системы сборки:

```bash
bazel test //app:tests
```

Чтобы также применить <.localized_link href="/guides/features/test-insights/flaky-tests/bazel">карантин</.localized_link>, запускайте тесты через обёртку Tuist. Аргументы после `--` передаются в `bazel test`:

```bash
tuist bazel test -- //app:tests
```

## Что отслеживается {#what-is-tracked}

Tuist разбирает отчёты `test.xml` и захватывает вывод `test.log`, который Bazel генерирует для каждой цели тестирования, а затем агрегирует их в общую модель запусков тестов. Каждый запуск фиксирует:

- Статус прохождения, сбоя и пропуска каждого тест-кейса вместе с длительностью.
- Цель тестирования, класс и структуру набора тестов.
- Попытки повторного запуска, если Bazel настроен на повтор нестабильных тестов.
- Вывод ошибок, захваченный из `test.log` цели.

Страницы **Запуски тестов**, **Тест-кейсы** и отдельных тестов работают для Bazel так же, как и для других систем сборки.

## Генерация JUnit-отчётов по каждому тест-кейсу {#per-case-junit-reports}

Строки по отдельным тест-кейсам зависят от того, записывает ли цель тестирования JUnit-файл `test.xml` по пути `$XML_OUTPUT_FILE`, который предоставляет Bazel. Если раннер не создаёт такой файл, Bazel использует сгенерированный отчёт с одним тест-кейсом, названный по имени цели, и Tuist показывает одну строку на цель (помеченную как **Цель Bazel** в списке тест-кейсов), при этом исходный `test.log` остаётся доступен на странице запуска.

Большинство правил тестирования Bazel уже создают полноценный `test.xml`:

- `java_test` и `kt_jvm_test`: JUnit встроен.
- `cc_test` с GoogleTest: раннер записывает JUnit при компиляции с недавней версией gtest; в старых конфигурациях требуется `--gtest_output=xml:$XML_OUTPUT_FILE`.
- `py_test`: используйте pytest с `--junitxml=$XML_OUTPUT_FILE` или раннер pytest из `rules_python`.
- `go_test`: передайте вывод `go test -json` через `gotestsum --junitfile=$XML_OUTPUT_FILE` или оберните вспомогательным скриптом, генерирующим JUnit.

`rust_test` из `rules_rust` и `rules_rs` использует стандартный механизм `libtest`, который не создаёт JUnit-отчёты в стабильной версии Rust. Оберните цель тестирования скриптом, который разбирает вывод `libtest` и записывает JUnit в `$XML_OUTPUT_FILE`; так вы сохраните строки по отдельным тест-кейсам в Tuist, а запуск останется одной целью тестирования Bazel.

## Идентификация тестов {#test-identity}

Тест-кейсы идентифицируются по метке цели, имени класса (с откатом к имени набора тестов) и имени теста. Это позволяет разделять методы с одинаковыми именами в разных классах. Старые отчёты, использовавшие другое имя охватывающего набора тестов, сохраняют историю под старой идентификацией; изменения состояния, применённые к старой идентификации, нужно повторно применить к новой, а команда предупреждает, когда сбой соответствует старой идентификации, чтобы вы знали, какую политику перенести.

## Передача контекста CI {#providing-ci-context}

Tuist считывает информацию о коммите и ветке Git из метаданных сборки Bazel, чтобы запуски на одном и том же коммите можно было сравнивать между окружениями. Большинство систем непрерывной интеграции уже устанавливают эти значения; если ваша система этого не делает, передайте их явно:

```bash
tuist bazel test -- \
  --build_metadata=CI=true \
  --build_metadata=GIT_COMMIT="$GIT_COMMIT" \
  --build_metadata=GIT_BRANCH="$GIT_BRANCH" //app:tests
```

Тот же флаг `--build_metadata` описан на странице <.localized_link href="/guides/features/build-insights/bazel#custom-metadata">Аналитика сборок Bazel</.localized_link> для маркировки вызовов, поэтому один набор флагов покрывает обе области.

## Нестабильные тесты и карантин {#flaky-tests-and-quarantine}

Повторные запуски, обнаружение нестабильности между запусками и карантин по отдельным тест-кейсам (Игнорировать и Пропустить) работают через `tuist bazel test`. Полный рабочий процесс описан в разделе <.localized_link href="/guides/features/test-insights/flaky-tests/bazel">Нестабильные тесты в Bazel</.localized_link>.

## Хранение данных {#data-retention}

Tuist хранит вызов Bazel, породивший запуск теста, его логи и ожидающие обработки записи о приёме тестов в течение 90 дней. Тест-кейсы и история их запусков используют ту же модель, что и в других системах сборки, и не подпадают под этот срок. Полная политика описана в разделе <.localized_link href="/guides/server/data-retention">хранение данных</.localized_link>.