Files
airflow-greenplum/TESTING.md
T
ddadmin 35144e49f6 docs: согласованы руководства загрузок и учебный маршрут
Руководства STG/ODS/DDS/DM сверены с действующими SQL и DAG,
ожидания учебных заглушек связаны с ТЗ. Самопроверка заданий
отделена от проверок разработки и исторических планов.

Для dim_routes закреплено обновление описательных полей только
у открытых версий. SQL, DAG, DDL и настройки стенда не менялись.

Проверки: make lint; make test (4 passed, 14 skipped); карта;
292 локальные ссылки; маршрут чтения и карта в Chromium.
Живой ETL не запускался.
2026-09-20 15:53:39 -04:00

119 lines
7.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Проверка изменений репозитория
Этот документ предназначен для работы над кодом, документацией и стендом.
Если вы выполняете учебное задание, начните с
[его самопроверки](docs/assignment/README.md#запуск-и-проверка): там объяснены
`*_dq.sql`, группы `bookings_validate` и порядок восстановления после SCD2-теста.
## Локальные проверки
Из корня репозитория:
```bash
uv sync
make lint
make test
```
`make lint` проверяет Black и isort для `airflow/` и `tests/`.
`make fmt` исправляет форматирование в этих каталогах.
Тесты находятся в трех файлах:
- [test_ods_sql_contract.py](tests/test_ods_sql_contract.py) проверяет
контракты SQL справочников ODS по исходным файлам.
- [test_dags_smoke.py](tests/test_dags_smoke.py) проверяет структуру DAG.
Если импорт `airflow` не предоставляет `DAG`, проверки пропускаются.
Смотрите причины пропусков: `uv run pytest -q -rs`.
- [test_ods_snapshot_integration.py](tests/test_ods_snapshot_integration.py)
по умолчанию пропускается; отдельный запуск описан ниже.
Успешный pytest с пропущенными smoke-тестами не подтверждает работоспособность
DAG в Airflow. Число выполненных и пропущенных тестов указывайте в отчете.
Для документации проверьте относительные ссылки и якоря, имена файлов,
таблиц и задач. Для карты выполните:
```bash
uv run docs/design/architecture-map/render.py --check
git diff --check
```
Сборщик сверяет карту с DDL, загрузками и ссылками. Действия в браузере
проверяются отдельно по [чек-листу карты](docs/design/architecture-map/README.md#проверка-в-браузере).
## Проверка на стенде
Подготовьте стенд по [README](README.md) и проверьте его состояние:
```bash
make up
docker compose ps
```
Порты берутся из `.env`: `AIRFLOW_WEB_PORT`, `GP_HOST_PORT`, `BOOKINGS_DB_PORT`.
Для локальных подключений используйте их, а для Greenplum внутри Docker-сети
применяется `GP_PORT` (по умолчанию 5432).
Загрузки используют Airflow Connections из Compose;
подробности находятся в [справочнике стенда](docs/stack.md).
Если изменились `Dockerfile.airflow` или `airflow/requirements.txt`, перед
`make up` выполните `make build`. Инициализация Bookings нужна при создании
стенда: `make bookings-init` пересоздает исходную базу из seed-дампа.
Не используйте ее для обычной проверки SQL на существующих данных.
Выполните DDL и загрузки по [порядку DAG](docs/dag_execution_order.md).
В Airflow откройте Graph и Log задач измененного слоя; в Greenplum
(`make gp-psql`) выполните проверки из его руководства:
[STG](docs/bookings_to_gp_stage.md#проверка-результата),
[ODS](docs/bookings_to_gp_ods.md#проверка-результата),
[DDS](docs/bookings_to_gp_dds.md#проверка-результата),
[DM](docs/bookings_to_gp_dm.md#проверка-результата).
Для проверки чтения через PXF используйте действующую внешнюю таблицу:
```sql
SELECT COUNT(*) FROM stg.bookings_ext;
SELECT * FROM stg.bookings_ext LIMIT 5;
```
Сравнить источник можно через `make bookings-psql`.
При ошибке соединения начните с `docker compose ps` и логов нужного сервиса,
затем проверьте настройки из `docs/stack.md`.
## Дополнительные прогоны
Интеграционный тест снимка ODS требует работающего Greenplum и базы `gp_dwh`:
```bash
RUN_ODS_INTEGRATION=1 uv run pytest -q tests/test_ods_snapshot_integration.py
```
Он создает, затем удаляет служебные таблицы
`public.it_stg_airports_ods` и `public.it_ods_airports_ods`.
Используйте тестовый стенд, где эти имена не заняты нужными данными.
Тест проверяет замену снимка, преобразование названий и DQ готового `airports`;
задания `airplanes` и `seats` он не проверяет.
`make e2e-etl` запускает DDL и два прохода STG → ODS → DDS → DM через API Airflow.
Скрипт использует `localhost:8080`; при другом `AIRFLOW_WEB_PORT` проходите
цепочку вручную. Каждый STG добавляет учебный день. Финальные SQL выводят
счетчики, но не превращают все неверные значения в ошибку завершения скрипта:
результаты нужно прочитать с учетом заглушек `main`.
`make e2e-smoke` начинает с `make clean` и **удаляет все Docker-тома стенда**,
затем инициализирует Bookings и выполняет E2E. Запускайте его только там,
где данные можно потерять. Обычный `make down` сохраняет тома;
`make stop`, затем `make up` подходят для перезапуска с сохранением данных.
[Исторический QA-план](docs/reference/qa-plan.md) сохраняет многодневные,
негативные и граничные сценарии полной реализации. Это материал для
подготовки отдельной диагностики: перед выполнением сверяйте его SQL
с текущей веткой и учитывайте операции очистки данных.
## Что указать в отчете
Укажите коммит, команды и результаты, включая пропуски тестов.
Разделите чтение исходников, проверки ссылок, действия в браузере и реальные
загрузки. Для запуска на стенде сохраните Run ID и логи проверенных задач.
Если ETL или интерфейс не проверялись, укажите это прямо.