Есть ли пункт модульного тестирования репозитория? Entity Framework 4.1

Question

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

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

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

Теперь вы можете использовать внедрение зависимостей для вставки фиктивного DBContext с помощью некоторого интерфейса IDBContext. Однако затем вы просто тестируете каждый метод репозитория, который в действительности просто пересылает dbcontext (который является поддельным).

Так что, если каждый метод репозитория не имеет много логики перед вызовом dbcontext, тогда он кажется немного бессмысленным?

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

Новый EF 4.1 делает это простым, поскольку он может создавать базу данных на лету на основе строки подключения в вашем тестовом проекте, затем вы можете удалить ее после запуска тестов с использованием методов dbcontext.Database.

Answer 1

Ваши возражения частично верны. Их правильность зависит от способа определения хранилища.

• Первый фальшивый или фиктивный репозиторий предназначен не для тестирования самого репозитория, а для тестирования слоев с использованием репозитория.
• Если репозиторий предоставляет IQueryable и верхний уровень может создавать запрос linq-to-entity, то для репозитория mocking необходимо проверить несуществующую логику. Вам нужно тестирование интеграции и выполнить запрос к реальной базе данных тестирования. Вы можете либо повторно развернуть базу данных для каждого теста, что сделает его очень медленным, либо вы можете запустить каждый тест в транзакции и откатить его по завершении теста.
• Если хранилище не предоставляет IQueryable, вы все равно можете думать о нем как о чёрном ящике и высмеивать его. Логика запросов будет находиться внутри хранилища, и она будет тестироваться отдельно с помощью интеграционных тестов.

Я хотел бы отослать вас к множеству других ответов о самом хранилище и тестировании .

Answer 2

Лучший подход, который я видел, - это архитектура Sharp, где они используют базу данных SQLLite, созданную в TestFixtureSetup на основе информации о сопоставлении NHibernate.

Затем тесты репозитория используют эту базу данных в памяти.

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

1) База данных временная - не нужно беспокоиться ни о конфигах строки соединения, ниВам нужен полный БД, находящийся где-нибудь на сервере, чтобы использовать модульный тест.

2) Установка быстрая, и тесты одинаковые, как и все в памяти.

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

http://wiki.sharparchitecture.net/default.aspx?AspxAutoDetectCookieSupport=1

Возможно использоватьтот же подход с EF.