LINQ to SQL: поддельный репозиторий с отношениями «многие ко многим»?

Question

У меня есть две таблицы, Клиенты и Администраторы, которые связаны между собой таблицей ClientAdministrators.

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

У меня есть класс FakeRepository, который реализует мой интерфейс репозитория, и у меня есть несколько внутренних списков объектов для запроса к классу обслуживания.

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

Dim clients = From c in _repository.GetAllClients _
              Select New ClientBizObj With {.ID = c.ID, _
                                            .ClientName = c.ClientName, _
                                            .Admins = (From a in c.ClientAdministrators _
                                                       Select a.Administrator.UserName).ToList}

Это говорит мне о том, что c.ClientAdministrators является EntitySet (для ClientAdministrator).

Как я могу подделать это отношение в моем классе FakeRepository, чтобы оно перестало выдавать исключения NullReferenceExceptions?

Мне все равно, если не вернет никаких администраторов, мне просто нужно, чтобы объект Client был возвращен успешно.

Answer 1

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

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

Существует несколько инструментов для насмешек, чтобы сделать это легко. Среди них одним из самых простых в использовании (и с открытым исходным кодом для загрузки) является moq . Используя moq, вы сможете смоделировать весь уровень доступа к данным для тестирования, поэтому вам даже не нужно создавать собственный класс FakeRepository.

Answer 2

Это должно быть одной из причин, по которой Рой Ошерове (главный архитектор в TypeMock и автор книги «Искусство модульного тестирования») рекомендует, чтобы операции с базой данных не подвергались фальсификации. Он рекомендует, чтобы такое тестирование было отнесено к интеграционным тестам , и чтобы в таком тестировании участвовала действительная база данных.

Answer 3

Вы можете использовать Dev Magic Fake, чтобы подделывать БД, а не подделывать БД, другими словами, вы можете подделывать пользовательский интерфейс, сделав следующее:

[HttpPost]
public ActionResult Create(Client model)
{
   var repository = new FakeRepository<Client>();
   repository.Save(model)

Для получения дополнительной информации см. DevMagicFake на CodePlex

devmagicfake.codeplex.com

Спасибо

M.Radwan