Модульное тестирование базы данных. Каков наилучший подход к тестированию базы данных для корпоративного решения с CI, имеющим филиалы и тяжелые базы данных? - PullRequest
2 голосов
/ 18 октября 2010

Итак, ситуация следующая : У нас есть очень старый продукт, в котором есть десятки решений. Многие из них запускают разные модульные тесты, некоторые MSTest, некоторые NUnit. Есть много тестов, которые тестируют базу данных, а некоторые зависят от данных. Другими словами, они исполняют код, чтобы проверить, есть ли у клиента Andriy заказы на продукты A и B. Я знаю, что это неправильно, но я, как и говорил, этот продукт был разработан многими командами в разное время.

В настоящее время многие команды продолжают вносить изменения в проекты, и изменения адресованы различным веткам. Среды сборки создаются в режиме CI. Таким образом, мы сталкиваемся с проблемой поддержания этих тестов. Мы потратили слишком много времени и усилий на поддержание работоспособности тестов. Поскольку базы данных с тестовыми данными действительно тяжелые, у нас не может быть отдельной базы данных для каждой ветви, но мы можем хранить чистые образцы баз данных (200 МБ) для каждой из ветвей, но в этом случае многие тесты не пройдут.

Я уже думал об этом, и у меня есть какой-то предварительный план, такой как :

1) Избавление от тестов, зависящих от данных, путем их удаления или (если возможно) перезаписи для вставки данных и отката сразу после выполнения теста.

2) Переместить все специфичные для базы данных тесты в отдельные проекты, т. Е. Отделить интеграционные тесты от обычных модульных тестов

3) Создайте образец базы данных для каждой ветви и запустите интеграционные тесты отдельно.

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

1 Ответ

1 голос
/ 18 октября 2010

Для нашего текущего проекта мы отделили CI- от модульных тестов, именно так, как вы описываете, и это работает хорошо. Перейдя на NHibernate , мы можем использовать базу данных в памяти ( SQLite ) для тестирования зависимого от данных кода, который не может быть легко смоделирован *, но у нас также есть некоторая интеграция -типы, работающие на локальном тестовом сервере SQL Server. Во всех этих тестах указан атрибут MbUnit Rollback2 , и оба они вставляют нужные данные и запрашивают их в одном раунде, чтобы база данных не изменялась тестами.

NUnit + SharpTestEx используются для модульных тестов.

* Например, тест для проверки каскадных сопоставлений и наборов коллекций, IEquatable и правильности сопоставления схемы прежней таблицы.

...