TDD y ADO.NET Entity Framework

Question

He estado jugando con ADO.NET Entity Framework últimamente, y creo que se adapta a mis necesidades para un proyecto que estoy desarrollando. También me parece genial su naturaleza no invasiva.

Después de generar un modelo de datos de una base de datos existente, se enfrenta a la tarea de integrar el modelo generado y la lógica de su negocio. Más específicamente, estoy acostumbrado a probar la integración de mis clases que interactúan con el almacén de datos a través de simulaciones/resguardos de las interfaces DAL. El problema es que no puede hacer esto utilizando el marco de entidad de ADO.NET porque las entidades que genera son clases simples sin interfaz.

La pregunta es: ¿cómo aplico un enfoque TDD para el desarrollo de una aplicación que utiliza ADO.NET Entity Framework? ¿Esto es posible o debo migrar a otro conjunto de herramientas de generación DAL?

Answer 1

Una de las grandes críticas contra el Entity Framework ha sido que es intrínsecamente difícil de probar, por ejemplo, en ALT.Net Vote of No Confidence que se cotiza en gef.

Here is a blog post discutiendo cómo evitar esto, y poder probar su código sin tocar la base de datos, al usar Entity Framework.

Si la capacidad de prueba es una gran preocupación, es posible que desee consultar otro marco ORM, como NHibernate, al menos hasta que se publique Entity Framework 2.0.

Answer 2

"El estrecho acoplamiento de la infraestructura de persistencia a las clases de entidad elimina en gran medida la capacidad de utilizar de forma eficiente muy ajustados de retroalimentación ciclos en la lógica de negocio con pruebas automatizadas. En su actual estado, entidad EF clases no pueden ser eficazmente unidad probado independientemente de la base de datos.

la eficiencia de la unidad automatizada pruebas de objetos de comportamiento es en gran parte una cuestión de cuán fácil es la mecánica de la configuración de datos de prueba y qué tan rápido se pueden ejecutar las pruebas. Utilizando la base de datos real hará que los datos de configuración prueba más laborioso, introducir datos relacionales para satisfacer restricciones que no son pertinentes a la prueba, y hacer que la ejecución de pruebas un orden de magnitud más lenta .

La capacidad de un equipo para hacer evolutiva diseño y la entrega incremental es dañados por la falta de atención del marco de la entidad al software principios de diseño fundamentales como la separación de preocupaciones "

robado descaradamente desde aquí:. http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Answer 3

Si está buscando específicamente herramientas de generación DAL, tendrá dificultades para integrar esto con TDD. La mayoría de las herramientas de generación de dal que conozco también generan sus objetos comerciales y los vincula estrechamente con DAL, lo que dificulta las pruebas.

Puede ver herramientas de mapeo OR como nHibernate y quizás Linq a sql que permiten "ignorancia de persistencia", puede definir sus objetos comerciales usted mismo y no tienen enlaces a DAL ni a ningún otro código de infraestructura. Esto hace que probar la lógica de su negocio por separado desde su base de datos sea mucho más fácil. Descubrí que también permite que otros escenarios, como clientes ocasionalmente conectados, sean mucho mejores.

Answer 4

Acepto que la versión 1 de Entity Framework es un delito contra el diseño y definitivamente obtuvo mi voto de no confianza. Sin embargo, le doy el crédito al equipo de producto de EF por reconocer el fracaso y responder abriendo su proceso de diseño a la comunidad. El próximo lanzamiento no va a ser perfecto, puede que ni siquiera esté listo para su uso en una aplicación de nivel de producción, pero creo que finalmente están empezando a comprender qué es importante para los usuarios que saben que el mal diseño es un mal negocio. Dicho eso ... todavía sospecho. Los comentarios continuos en tiempo de diseño son nuevos para estos tipos y he leído bastantes declaraciones en el blog ADO.NET que levantan banderas rojas brillantes. Veremos cómo funciona con el lanzamiento de .NET 4.0.

Parecen estar tratando sin embargo:

Test-Driven Development Walkthrough with the Entity Framework 4.0

Answer 5

Aunque, la pregunta original ha sido contestada, siento que debo añadir algo:

Actualmente estoy usando Entity Framework 4.0 en un sitio de intranet que estoy construyendo. Puedo probar todo en mi lógica de negocios y controladores sin una conexión de base de datos usando el soporte POCO que se ha agregado.

Aunque, los POCO se pueden generar a partir de la nueva plantilla t4 incluida en VS 2010, algo que no he podido encontrar en VS 2010 es una plantilla t4 para generar el contexto del objeto (el contexto del objeto básicamente funciona como una unidad de trabajo incorporada para EF y es esencial para mapear sus objetos EF a POCO). Afortunadamente Joachim Lykke Andersen en su publicación de blog Entity Framework 4.0 Beta 1 – POCO, ObjectSet, Repository and UnitOfWork escribió una plantilla t4 para generarla y ha sido muy útil. Si busca una solución usando el EF4 que sea comprobable sin una conexión a la base de datos, le recomiendo implementar algo similar a su solución, que incluye un repositorio genérico, un contenedor de unidad de trabajo y una fábrica de unidades de trabajo. Ha sido de mucha ayuda.

Lo mejor de la suerte.

Answer 6

Esta respuesta ha cambiado a "Sí, puede".

Puede generar POCO e interfaces usando plantillas T4 personalizadas como https://entityinterfacegenerator.codeplex.com/, luego crear objetos de burla para probar EF dentro y fuera sin tocar la base de datos.