[Unit-Testing] TDD и ADO.NET Entity Framework


Answers

Хотя на исходный вопрос был дан ответ, я чувствую, что могу что-то добавить:

В настоящее время я использую Entity Framework 4.0 на интрасети, которую я создаю. Я могу проверить все в своей бизнес-логике и контроллерах без подключения к базе данных с помощью поддержки POCO, которая была добавлена.

Хотя POCO можно создать из нового шаблона t4, включенного в VS 2010, то, что я не смог найти в VS 2010, является t4-шаблоном для создания вашего контекста объекта (контекст объекта в основном работает как встроенный блок работы для EF и имеет важное значение для отображения ваших объектов EF в POCOs). К счастью, Joachim Lykke Andersen в своем блоге Entity Framework 4.0 Beta 1 - POCO, ObjectSet, Repository и UnitOfWork написал шаблон t4 для его создания, и это было очень полезно. Если вы будете использовать решение с использованием EF4, которое можно тестировать без подключения к базе данных, я настоятельно рекомендую реализовать что-то похожее на его решение, которое включает в себя общий репозиторий, единицу рабочей обертки и единицу работы фабрики. Это было очень полезно.

Удачи.

Question

В последнее время я играю с ADO.NET Entity Framework, и я считаю, что это соответствует моим потребностям в проекте, который я разрабатываю. Я также считаю прохладным его неинвазивный характер.

После создания модели данных из существующей базы данных вы столкнулись с задачей интеграции сгенерированной модели и вашей бизнес-логики. Более конкретно, я привык к интеграции - тестируйте свои классы, которые взаимодействуют с хранилищем данных через mocks / stubs интерфейсов DAL. Проблема в том, что вы не можете сделать это, используя ADO.NET Entity Framework, потому что созданные им объекты - это простые классы без интерфейса.

Возникает вопрос: как применить TDD-подход к разработке приложения, использующего ADO.NET Entity Framework? Возможно ли это, или я должен перейти на другой набор инструментов DAL?




Этот ответ изменился на «Да, вы можете».

Вы можете создавать POCO и интерфейсы с помощью настраиваемых шаблонов T4, таких как https://entityinterfacegenerator.codeplex.com/ , а затем создавать насмешливые объекты для проверки входа и выхода EF без попадания в базу данных.




«Тесное связывание инфраструктуры персистентности с классами сущностей в значительной степени исключает возможность эффективного использования очень жестких циклов обратной связи в бизнес-логике с автоматическим тестированием. В своем текущем состоянии классы объектов EF нельзя эффективно тестировать отдельно независимо от базы данных.

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

Способность команды выполнять эволюционный дизайн и инкрементную доставку повреждается невнимательностью Entity Framework к фундаментальным принципам разработки программного обеспечения, таким как разделение проблем ».

Непосредственно украдены отсюда: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/






Links