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

12

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

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

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

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

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

Пример:

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

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

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

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

unit-testing sql tdd user87166
источник
Это не TDD, если инструмент, который вы тестируете, уже существует. Просто напишите обычные тесты.
Роберт Харви
@RobertHarvey В действительности инструмент ETL ничем не отличается от .Net Framework при написании кода на C #, не так ли? Таким образом, инструмент существует так же, как существует .Net Framework, но вы можете сделать TDD в C #
user87166
Я бы не стал тестировать методы Framework. Я предполагаю, что они уже работают. Если вы тестируете конфигурацию для инструмента ETL, вам не нужно заново создавать логику в инструменте ETL, чтобы сделать это; просто используйте инструмент.
Роберт Харви
1
Затем напишите тесты, используя ожидания, которые вы ожидаете получить от ETL, предложенные данные и предложенную конфигурацию. Сделайте им концептуальные тесты, если хотите, но функциональность уже существует. Чистая «сначала проверка» предназначена для вещей, которые еще не существуют. Что бы вы ни делали, не изобретайте инструмент ETL!
Роберт Харви
2
«с тех пор как возраст в базовых данных изменился» - что такого сложного в предоставлении стабильных данных испытаний в качестве входных данных? Если требуются расчеты в зависимости от времени, смоделируйте опорный таймер.
Док Браун

Ответы:

2

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

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

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

dietbuddha
источник
0

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

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

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

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