# Добавление тестов на основе данных с помощью dbt Wizard

Используйте dbt Wizard CLI, чтобы выявлять значимые пробелы в покрытии тестами, проверять предположения на текущих данных хранилища и создавать целевые тесты данных dbt.

В этом рабочем процессе используется встроенный агент `test_writer`. В отличие от запроса, в котором тесты указаны заранее, `test_writer` начинает с метаданных проекта и оценки значимости моделей, формулирует возможные проверяемые утверждения и проверяет их на доступных данных, прежде чем предлагать изменения YAML.

Рабочий процесс в CLI

Встроенный агент `test_writer` доступен в dbt Wizard CLI. Сведения о доступности и поведении агента см. в разделе [Использование субагентов с dbt Wizard CLI](https://docs.getdbt.tech/docs/dbt-ai/wizard-subagents.md).

## Предварительные требования

Прежде чем начать:

* [Установите и настройте dbt Wizard CLI](https://docs.getdbt.tech/docs/dbt-ai/wizard-cli.md).
* Запустите dbt Wizard из проекта dbt с актуальным файлом `target/manifest.json`.
* Настройте подключение для разработки, позволяющее запрашивать данные моделей, которые вы хотите проверить.
* Выполните сборку соответствующих моделей, если их объекты в среде разработки ещё не существуют.
* Решите, следует ли исключить из профилирования столбцы с конфиденциальными данными или объекты, запросы к которым требуют значительных ресурсов.

Запросы к хранилищу могут расходовать вычислительные ресурсы и выводить значения данных в сеансе терминала. Проверяйте предлагаемые запросы и соблюдайте политики доступа к данным вашей организации.

## Выберите ограниченную область работы

Начните с одной модели или небольшой части проекта. Так предлагаемые тесты будет проще проверить, а объём запросов к хранилищу останется ограниченным:

```text
Use test_writer to improve test coverage for stg_customers. Inspect its existing
tests and downstream importance, validate candidate assumptions against current
data, and propose only high-signal tests. Do not change model SQL.
```

Вы также можете попросить dbt Wizard найти отправную точку:

```text
Use test_writer to find three important models with weak test coverage. Prioritize
high fan-out models and models that define a business grain. Explain the ranking
before writing tests.
```

Укажите ограничения в запросе. Например, перечислите столбцы, которые нельзя запрашивать, ограничьте количество моделей или попросите dbt Wizard не создавать собственные универсальные тесты.

## Проверьте анализ покрытия тестами

Прежде чем агент `test_writer` начнёт записывать YAML, попросите его объяснить:

* Для каких моделей и столбцов уже есть тесты.
* Почему выбранная модель важна для зависимых ресурсов.
* Какой уровень детализации или какое бизнес-правило отражает каждый предлагаемый тест.
* Какие варианты основаны на коде или метаданных, а какие выведены из данных.
* Какой запрос к хранилищу позволит проверить каждое предположение.

Наиболее ценные варианты тестов защищают контракты моделей и бизнес-логику, а не просто проверяют структуру текущей выборки.

| Предлагаемый тест | Что следует проверить                                                                                                                    |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `not_null`        | Столбец обязателен с точки зрения уровня детализации модели, контракта или зависимой логики, а имеющиеся значения null были исследованы. |
| `unique`          | Столбец или сочетание столбцов соответствует предполагаемому уровню детализации, и проверки на дубликаты подтверждают это предположение. |
| `relationships`   | Родительский ресурс и ключ являются эталонными, а значения без соответствия в родительском ресурсе были исследованы.                     |
| `accepted_values` | Поле представляет собой перечисление с регламентированным набором значений, а не просто список значений, полученных одним запросом.      |

Если данные опровергают предлагаемое утверждение, исследуйте расхождение. Не добавляйте фильтр автоматически и не ослабляйте тест лишь для того, чтобы он прошёл.

## Одобрите проверки в хранилище

`test_writer` может использовать предварительные запросы к хранилищу для проверки предположений об уникальности, допустимости значений null, связях и наблюдаемых значениях. Прежде чем одобрить запрос, убедитесь, что:

* Он использует ожидаемые целевую среду и объект данных.
* Выбранные столбцы соответствуют политикам доступа к данным.
* Его фильтры и ограничения не скроют нарушение условия, которое должен контролировать тест.
* Ожидаемые объём сканирования и время выполнения приемлемы.

Перед одобрением можно попросить сократить объём запроса или сделать его более целевым:

```text
Validate the proposed grain without selecting customer attributes. Query only
customer_id and aggregate counts, and explain any sampling or date filter.
```

## Проверьте предлагаемые тесты

Для каждого предлагаемого изменения YAML убедитесь, что:

* Тест выражает предусмотренное правило, а не случайное свойство текущих данных.
* Тест привязан к нужной модели и нужному столбцу.
* Синтаксис YAML соответствует версии dbt, используемой в проекте.
* Существующие тесты не дублируются.
* Имена тестов, аргументы, конфигурация и уровень серьёзности соответствуют соглашениям проекта.
* Набор изменений не содержит посторонних изменений документации или моделей.

Агент `test_writer` создаёт тесты. За их запуск отвечает стандартный процесс валидации dbt Wizard. Выберите подходящий [уровень валидации](https://docs.getdbt.tech/best-practices/how-to-use-wizard/wizard-3-validate-changes.md#choose-a-validation-level) и изучите все строки, не прошедшие проверку, прежде чем принять окончательное изменение.

## Исследуйте предлагаемый тест, завершившийся ошибкой

Если новый тест не проходит, сохраняйте исходное предположение в фокусе, пока выясняете, о чём говорят данные:

```text
The proposed unique test on customer_id fails. Show the duplicate pattern,
check whether the intended grain uses another column, and tell me whether this
is a model defect, a source-data issue, or a bad test assumption. Do not modify
the test until you explain the evidence.
```

Возможные результаты: исправление дефекта модели, документирование ограничения источника, выбор правильного составного ключа, определяющего уровень детализации, или отказ от предлагаемого теста.

## Учитывайте ограничения

Генерация тестов на основе данных по-прежнему требует инженерной оценки:

* Текущие данные могут подтверждать или опровергать предположение, но не определяют бизнес-правило.
* Успешно пройденный тест может не учитывать будущие значения, данные, поступающие с задержкой, и разделы данных, к которым не выполнялись запросы.
* Тестам `accepted_values` нужен регламентированный список значений, если могут появляться новые допустимые значения.
* Доступ к хранилищу, разрешения, неактуальные объекты данных и использование выборок могут ограничивать доступные свидетельства.
* Большое количество тестов может увеличивать время сборки, не улучшая значимое покрытие.
* Тесты не заменяют контракты моделей, проверки актуальности источников, мониторинг или проверку владельцем модели.

## Связанная документация

* [Валидация изменений dbt с помощью dbt Wizard](https://docs.getdbt.tech/best-practices/how-to-use-wizard/wizard-3-validate-changes.md)
* [Использование субагентов с dbt Wizard CLI](https://docs.getdbt.tech/docs/dbt-ai/wizard-subagents.md)
* [Тесты данных](https://docs.getdbt.tech/docs/build/data-tests.md)
* [Рекомендации по тестированию](https://docs.getdbt.tech/best-practices/writing-custom-generic-tests.md)