Смотрите
Есть выгрузка ну очень большого объема данных. Большие не по количеству записей, а, в первую очередь, по количеству полей
На основе этих полей происходит какая-то сложная логика вычислений.
Вычисления состоят из модулей (Jobs, говорим про Spark)
Каждый модуль мы можем и должны покрыть юнит-тестами, чтобы гарантировать надежность этих джоб
При этом, в конечном счете, мы поставляем флоу - цепочку этих джоб, где результат вычислений одной джобы полностью или частично используеся для следующей.
Если бы я тестировал какой-нибудь условный калькулятор, я бы подал на вход “5+3” и ожидал бы ответ 8. Обртите внимание, чтобы понять, чего я жду, я должен сам провести расчет и сверить его с выводом программы
Алгоритмы, используемые в джобах чертовски сложные. А цеполчка алгоритмов - тем более.
По аналогии с калькулятором, чтобы проверить, что флоу отработал корректно, я должен где-то сам реализовать весь полный алгоритм и сверить с результатом.
Но, принимая во внимание сложность, я делаю такую же работу что и сам разработчик. Что не очень эффективно
И так я попадаю в патовую ситуацию: мне нужны эталонные данные ждля ожидаемого результата. Но сидеть и писать алгоритм для каждой новой джобы, которых будут десятки и сотни - будет напряжно. Разработчиков 10, а тестировщиков 3.
Кто как тестирует ETL системы? Откуда вы берете данные для тестов?
Смотрел всякие видосы - там на эту тему не заморачиваются и показывают примеры 2+2 - ждем 4