TDD и ADO.NET Entity Framework

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

В настоящее время я использую 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, которое можно тестировать без подключения к базе данных, я настоятельно рекомендую реализовать нечто похожее на его решение, которое включает в себя общий репозиторий, упаковщик единиц работы и фабрику единиц работы. Это было очень полезно.

Желаем удачи.

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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