Структура предприятия 4.0 модульных тестирования
Я осуществил модульное тестирование вроде этой статьи с поддельным контекстом объекта и IObjectSet с ПОСТЕПЕННО в EF4.
Но я не уверен, как осуществить несколько методов на моем поддельном контексте объекта для тестирования. У меня есть методы CreateQuery и ExecuteFunction в моем интерфейсе контекста объекта так, чтобы я мог выполнить ESQL и Хранимые процедуры, но я не могу (легко) осуществить их в своем поддельном контексте объекта.
Альтернатива должна была бы использовать тест дважды моего хранилища вместо двойного из моего контекста объекта, как предложено здесь:
http://social.msdn.microsoft.com/Forums/en-US/adonetefx/thread/c4921443-e8a3-4414-92dd-eba1480a07ad/
Но это означало бы, что мое реальное хранилище не проверяется и, казалось бы, просто обошло бы проблему.
Кто-либо может предложить какие-либо рекомендации?
2 ответа
Насколько я могу судить по вопросу, вы пытаетесь проверить слишком много одновременно. Имейте в виду принцип Single Responsibility Principle.
Когда мы проводим юнит-тест, мы используем абстрактные репозитории для абстрагирования кода доступа к данным подальше от остальной части приложения. С этой точки зрения мы тестируем только потребителей репозиториев, а не какой-то конкретный репозиторий. Такие потребители должны заботиться только о репозиториях, а вовсе не о каком-либо "объектном контексте" - это была бы Абстракция течи .
Представьте себе, что вас неожиданно просят подключить потребителей репозитория к совершенно другому уровню данных (например, к сервису, основанному на REST-технологиях). В таких случаях даже абстрактный контекст объекта не имеет смысла. Вы можете никогда не ожидать, что это произойдет, но даже в этом случае, один лишь мыслительный эксперимент является довольно хорошим индикатором течи абстракции.
Объектный контекст представляет собой детальную реализацию вашей конкретной реализации Репозитария, в которой используется EF. В других реализациях контекст объектов может вообще не требоваться.
Тем не менее, Вы можете все же протестировать саму реализацию EF. В этом может быть много смысла, но это совсем другой набор юнит-тестов с совершенно другим назначением. Вместо того, чтобы тестировать потребителей ваших абстрактных Репозиториев, вы сейчас тестируете конкретную реализацию репозитория. В этом случае нет необходимости проходить через интерфейсы - с конкретными типами можно поговорить прямо здесь
.Можно ли протестировать фактические репозитории с помощью базы данных в памяти, такой как SQLite? Для Entity Framework существует поставщик SQLite.
Похоже, что раздел SSDL в файле edmx связан с провайдером. Если вы сгенерируете модель из базы данных Sql-сервера, будет установлен provider = "System.Data.SqlClient". Это также будет установлено, если вы создаете базу данных sql-server из модели сущностей.
Я действительно хотел бы, чтобы в моем производственном коде использовался поставщик System.Data.SqlClient, а в моих модульных тестах - поставщик System.Data.SqLite.