Как вы тестируете \ используете методы TDD для ETL и отчетов проектов?

Проекты ETL - это проекты, созданные с использованием инструмента ETL (Извлечение - Преобразование - Загрузка), такого как SSIS, PowerCenter и т. Д.

Обычно это включает чтение данных из внешнего источника, загрузку их в промежуточную базу данных, выполнение определенных преобразований и загрузку в конечную базу данных.

Простым примером будет использование SSIS для чтения файлов Excel, предоставленных школьными учителями с использованием SSIS, и загрузки их в базу данных. Затем напишите хранимые процедуры или несколько пакетов служб SSIS для расчета оценок каждого учащегося и загрузите эти данные в магазин данных \ склад

Затем вы создаете хранимые процедуры поверх витрины, чтобы генерировать выходные данные, которые используются инструментами отчетности (SSRS \ Excel \ и т. Д.) Для генерации визуализаций.

Я пытаюсь понять, как выполнить TDD и надлежащее модульное тестирование в этом сценарии. Тесты ETL в основном сводятся к тому, чтобы данные, загруженные в таблицы промежуточных таблиц, являлись правильным подмножеством данных из источника. Таким образом, реализация теста для него приводит к реализации мини-версии ETL. Выходные данные отчетов SP зависят от данных в самих таблицах, поэтому невозможно получить стабильный набор выходных данных без кошмара обслуживания, даже если вы создадите базу данных, содержащую очищенные тестовые данные.

Пример:

Спринт 1: таблица ученика содержит имя, возраст, класс

Вы создаете тестовые данные для этой таблицы, и модульные тесты на основе этого

Спринт 2. Поле добавляется в таблицу.

Теперь, если вы обновите данные в поле студента, чтобы заполнить гендерный атрибут, тестовые случаи станут недействительными, так как данные изменились. И если вы этого не сделаете, вы не можете создать тестовые случаи, которые требуют столбца пола

В прошлом я использовал Acceptance Test Driven Development . Код ETL часто распределяется между различными этапами / языками и технологиями И тесно связан. Большинство процессов ETL зависят от последовательности преобразований в конвейере.

Риск использования модульного теста только в ETL состоит в том, что он не охватывает интеграцию. Последовательность преобразований является частью реальных преобразований во многих ETL. Если бы я тратил ресурсы на создание автоматизированного набора тестов, я бы удостоверился, что он также охватывает последовательность.

Я бы сосредоточился на TDD для каждой уникальной последовательности преобразования или, по крайней мере, включил бы эти тесты в больший набор тестов. Если комбинаций слишком много, вам, возможно, придется выбирать, какие последовательности тестировать. Идея состоит в том, чтобы проверить конвейер ETL для набора (-ов) данных, на котором он будет использоваться. А также убедитесь, что у вас есть тестовое покрытие на весь ваш код.

ETL может быть выполнен с помощью TDD и тестируется очень похоже на большинство проектов, т.е.

написать тест, который не удается (красный) исправить ошибку (зеленый) сделать код работоспособным и обслуживаемым (рефакторинг)

Так что для ETL это может быть:

• написать скрипт для загрузки 1 записи
• ошибка (источник данных не определен)
• определить источник [зеленый]
• нет необходимости в рефакторе
• написать тест для загрузки 1 записи с заполнением только 1 поля
• ошибка (код для этого поля не написан)
• определить детали кода для этого поля
• рефакторинг
• определить ошибочные тесты, которые ищут атрибуты, имеющие допустимые значения [красный]
• и т.д