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

7.1 KiB
Raw Blame History

Проверка изменений репозитория

Этот документ предназначен для работы над кодом, документацией и стендом. Если вы выполняете учебное задание, начните с его самопроверки: там объяснены *_dq.sql, группы bookings_validate и порядок восстановления после SCD2-теста.

Локальные проверки

Из корня репозитория:

uv sync
make lint
make test

make lint проверяет Black и isort для airflow/ и tests/. make fmt исправляет форматирование в этих каталогах. Тесты находятся в трех файлах:

  • test_ods_sql_contract.py проверяет контракты SQL справочников ODS по исходным файлам.
  • test_dags_smoke.py проверяет структуру DAG. Если импорт airflow не предоставляет DAG, проверки пропускаются. Смотрите причины пропусков: uv run pytest -q -rs.
  • test_ods_snapshot_integration.py по умолчанию пропускается; отдельный запуск описан ниже.

Успешный pytest с пропущенными smoke-тестами не подтверждает работоспособность DAG в Airflow. Число выполненных и пропущенных тестов указывайте в отчете.

Для документации проверьте относительные ссылки и якоря, имена файлов, таблиц и задач. Для карты выполните:

uv run docs/design/architecture-map/render.py --check
git diff --check

Сборщик сверяет карту с DDL, загрузками и ссылками. Действия в браузере проверяются отдельно по чек-листу карты.

Проверка на стенде

Подготовьте стенд по README и проверьте его состояние:

make up
docker compose ps

Порты берутся из .env: AIRFLOW_WEB_PORT, GP_HOST_PORT, BOOKINGS_DB_PORT. Для локальных подключений используйте их, а для Greenplum внутри Docker-сети применяется GP_PORT (по умолчанию 5432). Загрузки используют Airflow Connections из Compose; подробности находятся в справочнике стенда.

Если изменились Dockerfile.airflow или airflow/requirements.txt, перед make up выполните make build. Инициализация Bookings нужна при создании стенда: make bookings-init пересоздает исходную базу из seed-дампа. Не используйте ее для обычной проверки SQL на существующих данных.

Выполните DDL и загрузки по порядку DAG. В Airflow откройте Graph и Log задач измененного слоя; в Greenplum (make gp-psql) выполните проверки из его руководства: STG, ODS, DDS, DM.

Для проверки чтения через PXF используйте действующую внешнюю таблицу:

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:

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-план сохраняет многодневные, негативные и граничные сценарии полной реализации. Это материал для подготовки отдельной диагностики: перед выполнением сверяйте его SQL с текущей веткой и учитывайте операции очистки данных.

Что указать в отчете

Укажите коммит, команды и результаты, включая пропуски тестов. Разделите чтение исходников, проверки ссылок, действия в браузере и реальные загрузки. Для запуска на стенде сохраните Run ID и логи проверенных задач. Если ETL или интерфейс не проверялись, укажите это прямо.