Тестируем ETL. Где брать ожидаемый результат?

Смотрите

Есть выгрузка ну очень большого объема данных. Большие не по количеству записей, а, в первую очередь, по количеству полей

На основе этих полей происходит какая-то сложная логика вычислений.
Вычисления состоят из модулей (Jobs, говорим про Spark)

Каждый модуль мы можем и должны покрыть юнит-тестами, чтобы гарантировать надежность этих джоб

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

Если бы я тестировал какой-нибудь условный калькулятор, я бы подал на вход “5+3” и ожидал бы ответ 8. Обртите внимание, чтобы понять, чего я жду, я должен сам провести расчет и сверить его с выводом программы

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

Но, принимая во внимание сложность, я делаю такую же работу что и сам разработчик. Что не очень эффективно

И так я попадаю в патовую ситуацию: мне нужны эталонные данные ждля ожидаемого результата. Но сидеть и писать алгоритм для каждой новой джобы, которых будут десятки и сотни - будет напряжно. Разработчиков 10, а тестировщиков 3.

Кто как тестирует ETL системы? Откуда вы берете данные для тестов?


Смотрел всякие видосы - там на эту тему не заморачиваются и показывают примеры 2+2 - ждем 4

Если используется уникальный алгоритм и нет ожидаемых данных вообще, то поможет только наверное качественное ревью логики (тем более что 10 разработчиков), и после того как убедитесь что все работает правильно, зафиксировать все автотестами с эталонными данными, которые получите от этого алгоритма.
Тестировал подобную задачку, но я в компасе пробовал линии по координатам отрисовать и смотрел попадают ли точки в нужные места

1 лайк