Модульное тестирование доменных служб на реальной базе данных

Question

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

Основная проблема, которую я вижу при живом тестировании моих репозиториев на основе SQL, - это согласованность базы данных. Например, после запуска теста аспекты «создания» уже выполнены. Повторный запуск их, очевидно, вызовет сбои, так как база данных больше не является чистой. Я думал о создании зеркальной базы данных, используемой только для этого типа тестирования. Он будет минимальным, содержит структуру, программируемость, ограничения и т. Д. Я также предоставил бы минимальный набор данных для определенных установленных тестов. Мое мнение заключается в том, что у меня могла бы быть хранимая процедура, которую я мог бы вызвать для сброса базы данных в «исходное» состояние с базовыми данными до начала выполнения теста.

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

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

Windows 7 (разработка) / Windows Server 2008 R2 (сервер) Visual Studio 2008 Team Edition (C #) Microsoft SQL Server 2008 Standard (Разработка / Сервер)

Я использую Team Build для запуска своих сборок, но это, скорее всего, не является фактором в рамках вопроса.

Answer 1

Например, после запуска теста аспекты «создания» уже выполнены. Повторный запуск их, очевидно, вызовет сбои, так как база данных больше не является чистой.

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

Spring имеет классы транзакционных модульных тестов, которые делают это легко. Вам просто нужен менеджер транзакций.

Answer 2

если вы на самом деле выполняете модульные тесты для своего хранилища, попадающие в базу данных, ВЫ НЕ ДЕЛАЕТЕ ЕДИНОЕ ТЕСТИРОВАНИЕ. Это может быть полезным тестом, но это не модульный тест. Это интеграционный тест. Если вы хотите сделать это и назвать это интеграционным тестом, тогда это прекрасно. Однако, если вы используете хорошие принципы проектирования в своих хранилищах, вам не нужно проверять базу данных, НИКОГДА, в своих модульных тестах.

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

Видите ли, хранилище, как и весь ваш код, должно следовать принципу единого размещения. По сути, ваше хранилище имеет ОДНОМ и ТОЛЬКО ОДНОМ репозитарии, и это должно связывать проблемы API модели предметной области с базовым технологическим уровнем доступа к данным (обычно ADO.Net, но может быть Entity Framework или L2S или любым другим). Следуя примеру вызовов ADO.Net, ваш репозиторий не должен брать на себя ответственность за фабрику для уровня данных и вместо этого должен зависеть от коллаборатора из интерфейсов данных ADO.Net (в частности, IDbConnection / IDbCommand / IDbParameter) так далее). Просто возьмите IDbConnection в качестве параметра конструктора и назовите его день. Это означает, что вы можете написать модульные тесты репозитория для интерфейсов и предоставить имитаторы (или подделки, или заглушки, или все, что вам нужно) и подтвердить, что необходимые методы, в порядке, с ожидаемыми входными данными сделаны. Зайдите в мой блог на эту тему -> http://blogs.msdn.com/b/schlepticons/archive/2010/07/20/unit-testing-repositories-a-rebuttal.aspx

Надеюсь, это поможет вам в будущем ошибиться в тесте и дизайне.

Кстати: если вы хотите провести модульное тестирование базы данных, вы можете. Просто используйте тесты базы данных Visual Studio. Его построили INTO против и был вокруг с VS2005. В этом нет ничего нового. Но я должен предупредить вас, они должны быть полностью ОТДЕЛЬНЫМИ юнит-тестами.

Answer 3

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

Answer 4

Вы можете использовать SQL Server Express (я делал это с 2005 года, но не пробовал с 2008), чтобы настроить базы данных "тестовой колоды", которые хранятся в виде файлов. Они могут быть возвращены в систему контроля версий, затем тестовые вспомогательные классы могут (а) скопировать их во временные папки, (б) включить запись и (с) подключиться к ним. Чтобы восстановить исходное состояние, удалите временную копию и повторите a-c.

Это огромная боль. Если вы можете справиться с транзакциями (как и предполагал Даффимо), я бы согласился. Болевые точки транзакций - это вложенные и распределенные транзакции - следите за тем, что в вашем коде.

Answer 5

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