Поддержание базы данных ориентированных тестов в актуальном состоянии

Question

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

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

Как правило, даже невозможно выполнить более новую версию службы длястарая (тестовая база данных) схема;это можно решить, имея два слоя моментальных снимков базы данных, один для инициализации (тестовый ввод) и другой, используемый исключительно для проверки (например, ожидаемый тестовый вывод).Схема / данные инициализации могут быть обновлены автоматически вместе с приложением, но, очевидно, не ожидаемыми выходными данными.

Я уже проходил это несколько раз, но я был бы признателен за ссылки на дополнительные материалы по теме.а также опыт, технологии и методологии людей, особенно в контексте Java, .NET и, возможно, чистых сред баз данных.

Этот вопрос намеренно несколько широк, потому что я не знаю, чему я научусь из него, но вот также его более узкая версия:

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

Answer 1

1. Это скорее вопрос организации комплекта тестов, чем наличия инфраструктуры, которая отслеживает изменения базы данных. Например - если вы используете модель персистентности Hibernate / EJB, то перед выполнением набора тестов вы можете создать базу данных из сопоставления объектов (например, с помощью Hbm2Ddl). Затем каждый тест создает необходимые объекты посредством сохранения сущностей (то есть без какого-либо прямого SQL). В сущности, в этом случае вы не имеете дело с базой данных напрямую, только через постоянный уровень в приложении. В конце выполнения схема базы данных удаляется.

2. С другой стороны, это вопрос процесса. Каждое изменение базы данных должно сохранять целостность тестов. Не так, когда некоторые люди вносят изменения в базу данных, не заботясь о целостности тестов. По сути, любое изменение в источниках не должно приниматься, если оно нарушает тесты, независимо от изменений кода или структуры базы данных.

Другими словами, должна быть определенная дисциплина в процессе разработки + правильная среда тестирования, настроенная и работающая через постоянный уровень (т.е. не тестовая база данных, которая является дампом производственной базы данных с тестами без или с минимальным набором вверх / демонтажа).