Есть ли смысл в модульном тестировании репозитория? Сущностная структура 4.1

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

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

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

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

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

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

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


unit-testing dbcontext entity-framework-4.1
person Mark    schedule 01.07.2011    source источник
comment
Я согласен. Тут особо и нечего сказать :)   -  person Enrico Campidoglio    schedule 01.07.2011

Ответы (2)


arrow_upward
4
arrow_downward

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

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

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

person Ladislav Mrnka    schedule 01.07.2011

arrow_upward
0
arrow_downward

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

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

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

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

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

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

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

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

person BonyT    schedule 01.07.2011
comment
Звучит интересно, но опять же это тестирование чего-то, что не пойдет в производство. Я предпочитаю создавать базу данных на лету для тестов локально или на сервере сборки, это легко сделать с помощью EF 4.1. - person Mark; 01.07.2011
comment
Ну, много модульных тестов, тестирование вещей, которые не будут запущены в производство. Каждый раз, когда у вас есть процесс FixtureSetup, вы вводите что-то, что является имитацией поведения реальной системы. Однако в целом я согласен - я еще не нашел, чтобы тесты такого рода стоили усилий по настройке. - person BonyT; 01.07.2011