Поддерживаемость тестирования интеграции баз данных

Question

Я занимаюсь разработкой процесса ETL, который извлекает бизнес-данные из одной базы данных в хранилище данных. Приложение НЕ использует NHibinate, Linq to Sql или Entity Framework. Приложение имеет собственные сгенерированные классы доступа к данным, которые генерируют необходимые операторы SQL для выполнения CUID.

Как можно себе представить, разработчики, которые пишут код, генерирующий пользовательский SQL, могут легко ошибаться.

Я хотел бы написать программу, которая генерирует данные тестирования (Arrange), затем выполняет процесс ETL (Act) и проверяет хранилище данных (Assert).

Я не думаю, что сложно написать такую ​​программу. Однако меня беспокоит то, что в прошлом моя компания пыталась сделать что-то похожее, и в итоге у нее было множество не поддерживаемых модульных тестов, которые постоянно терпят неудачу из-за множества новых изменений в схеме базы данных по мере добавления новых функций. 1007 *

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

Мне бы очень хотелось получить от сообщества отзывы о том, как написать такой интеграционный тест, который легко поддерживать. У меня есть несколько идей:

1. Сохраните резервную копию тестовой базы данных в системе управления версиями (TFS), разработчикам потребуется изменить резервную копию базы данных при изменении данных в источнике или хранилище данных.

2. Разработчики должны поддерживать данные тестирования через программу тестирования (в данном случае C #) вручную. Эта программа будет иметь базовую основу для разработчиков для создания своих данных тестирования.

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

Я приветствую любые предложения Спасибо

Answer 1

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

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

Грязный модульный тест - это только результат грязного производственного кода.Не обижайся.Это только мое мнение.Модульные тесты вынуждают кодеров поддерживать чистый стиль кодирования и поддерживать все это в более удобном для эксплуатации виде.потому что юнит-тесты (если они используются правильно) могут фокусироваться на проблемах более подробно.

С уважением, MacX

Answer 2

Во-первых, скажем, я считаю, что это хороший план, и я сделал нечто подобное, используя Oracle и PL / SQL несколько лет назад. ИМХО ваша проблема в основном организационная, а не техническая:

• У вас должен быть кто-то, кто отвечает за расширение и поддержку тестового кода.
• Ответственность за ведение тестовых данных должна быть четкой (и обеспечивать механизмы для легкого обслуживания тестовых данных; это же относится и к любым проверочным данным, которые могут вам понадобиться)
• Вся команда должна знать, что ни один код не попадет в производственную среду, если тест не пройден. Если тест не пройден, первоочередной задачей команды должно быть его исправление (код или тест, что угодно). Обучите их не работать с какой-либо новой функцией, пока тесты прерываются!
• После исправления ошибки, тому, кто его исправил, должно быть легко проверить, что часть интеграции, которая до этого не работала, впоследствии не перестала работать. Это означает, что должна быть возможность выполнить весь тест quick и легко с любой машины разработчика (или, по крайней мере, ее части). Быстрый может вызвать проблемы в процессе ETL, если ваш тест слишком большой, поэтому сосредоточьтесь на тестировании множества вещей с минимальным количеством данных. И, возможно, вы можете разбить весь тест на более мелкие части, которые можно выполнить пошагово.