TDD и ADO.NET Entity Framework

Одна из самых серьезных критических замечаний в адрес Entity Framework заключалась в том, что ее сложно протестировать, например, в ALT.Net вотум недоверия, процитированный gef.

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

Если возможность тестирования вызывает большую озабоченность, вы можете взглянуть на другую структуру ORM, такую ​​как NHibernate, по крайней мере, до тех пор, пока не будет выпущена Entity Framework 2.0.

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

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

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

Удачи.

Я согласен с тем, что версия 1 Entity Framework является преступлением против дизайна и определенно получила мой вотум недоверия. Я благодарен команде разработчиков EF за то, что они признали провал и открыли процесс разработки для сообщества. Следующий выпуск не будет идеальным, он может быть даже не готов для использования в приложении производственного уровня, но я думаю, что они наконец начинают понимать, что важно для тех, кто использует, кто знает, что плохой дизайн - плохой бизнес. При этом ... Я все еще подозреваю. Постоянная обратная связь во время разработки - новость для этих ребят, и я прочитал довольно много заявлений в блоге ADO.NET, которые поднимают яркие красные флажки. Посмотрим, как это пойдет с выпуском .NET 4.0.

Хотя они, похоже, пытаются:

Пошаговое руководство по разработке через тестирование с помощью Entity Framework 4.0

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

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

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

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

Если вы смотрите конкретно на инструменты генерации DAL, вам будет сложно интегрировать их с TDD. Большинство известных мне инструментов генерации dal также генерируют ваши бизнес-объекты и тесно связывают их с DAL, что затрудняет тестирование.

Вы можете взглянуть на инструменты OR-отображения, такие как nHibernate и, возможно, Linq to sql, которые включают «постоянное игнорирование», вы можете сами определять свои бизнес-объекты, и они не имеют ссылок на DAL или любой другой код инфраструктуры. Это значительно упрощает тестирование бизнес-логики отдельно от базы данных. Я обнаружил, что он также намного лучше позволяет использовать другие сценарии, такие как периодически подключаемые клиенты.

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

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