Як ви проводите тестування \ використання методів TDD для проектів ETL та звітів?


12

Проекти ETL - це проекти, створені за допомогою інструменту ETL (Extract - Transform - Load), такого як SSIS, PowerCenter тощо

Зазвичай вони включають в себе зчитування даних із зовнішнього джерела, завантаження їх у базу даних, а також певні перетворення та завантаження в кінцеву базу даних

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

Потім ви будуєте збережені процедури поверх марта для отримання результатів, які використовуються засобами звітування (SSRS \ Excel \ тощо) для створення візуалізації.

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

Приклад:

Спринт 1: Таблиця учнів містить ім'я, вік, ступінь

Ви створюєте тестові дані для цієї таблиці та на основі цього використовуєте одиничні тести

Спринт 2: До таблиці додається гендерне поле.

Тепер, якщо ви оновите дані у студентському полі для заповнення гендерного атрибута, тестові випадки недійсні з моменту зміни даних. І якщо ви цього не робите, ви не можете створювати тестові випадки, які потребують гендерної колонки


Це не TDD, якщо інструмент, який ви тестуєте, вже існує. Просто напишіть звичайні тести.
Роберт Харві

@RobertHarvey Насправді інструмент ETL нічим не відрізняється від .Net Framework при написанні коду C # чи не так? Отже, інструмент існує так само, як існує .Net Framework, але ви можете робити TDD в C #
user87166

Я також не перевіряв рамкові методи. Я припускаю, що вони вже працюють. Якщо ви тестуєте конфігурацію інструменту ETL, вам не потрібно заново створювати логіку в інструменті ETL; просто використовуйте інструмент.
Роберт Харві

1
Потім напишіть тести, використовуючи очікування, які ви очікуєте отримати від ETL, запропоновані дані та запропоновану конфігурацію. Зробіть їх, якщо вам подобається, концептуальні тести, але функціонал вже є. Чиста розробка "першим тестом" - це те, що ще не існує. Що б ви не робили, не винаходити інструмент ETL!
Роберт Харві

2
"оскільки вік в базових даних змінився" - що настільки важко забезпечити стабільні дані тесту як вхідні дані? Якщо пов'язані розрахунки залежно від часу, висміюйте контрольний таймер.
Док Браун

Відповіді:


2

Що раніше я робив - це використання тесту на прийняття тесту на прийняття . Код ETL часто поширюється на різних етапах / мовах та технологіях І щільно поєднаний. Більшість процесів ETL залежать від послідовності перетворень у трубопроводі.

Ризик використання одиничного тестування лише в ETL полягає в тому, що він не покриє інтеграції. Послідовність перетворень є рівною частиною фактичних перетворень у багатьох ETL. Якщо я витрачаю ресурси на створення автоматизованого тестового набору, я б переконався, що він охоплював також послідовності.

Я б зосередився на TDD для кожної унікальної послідовності трансформації або хоча б включив ці тести до більшого набору тестів. Якщо занадто багато комбінацій, можливо, доведеться вибрати та вибрати послідовності, які слід протестувати. Ідея полягає у валідації трубопроводу ETL для набору даних, на яких він буде використовуватися. А також переконайтесь, що у вас є тестове покриття на весь ваш код.


0

ETL можна виконати за допомогою TDD і тестів, приблизно аналогічно більшості проектів, тобто

написати тест, який не вдається (червоний) виправити збій (зелений) зробити код перформантом і ремонтом (рефактор)

Отже, для ETL це може бути:

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

Перші 8 кроків не мають нічого спільного з TDD, оскільки вони не залишають позаду ніяких тестів. Решта незрозуміло.
Булат
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.