unit testing - tutorial - TDD y ADO.NET Entity Framework
mstest tutorial (6)
"El estrecho acoplamiento de la infraestructura de persistencia a las clases de entidades elimina en gran medida la capacidad de utilizar de manera eficiente ciclos de retroalimentación muy ajustados en la lógica empresarial con pruebas automáticas. En su estado actual, las clases de entidad EF no pueden ser probadas de manera efectiva independientemente de la base de datos.
La eficacia de las pruebas unitarias automatizadas de objetos de comportamiento es, en gran medida, 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. El uso de la base de datos real hará que la configuración de los datos de prueba sea más laboriosa, introduzca datos para satisfacer las restricciones relacionales que no guardan relación con la prueba y haga que la ejecución de la prueba sea un orden de magnitud más lenta.
La capacidad de un equipo para hacer un diseño evolutivo y una entrega incremental se ve perjudicada por la falta de atención de Entity Framework a los principios fundamentales de diseño de software, como Separation of Concerns ".
Blatantly robado de aquí: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
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 a partir 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 al desarrollo de una aplicación que usa ADO.NET Entity Framework? ¿Esto es posible o debo migrar a otro conjunto de herramientas de generación DAL?
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 mirar herramientas de mapeo OR como nHibernate y quizás Linq a sql que habilitan la "ignorancia de persistencia", usted mismo puede definir sus objetos comerciales y no tienen enlaces al 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.
Una de las grandes críticas en contra del Marco de la Entidad ha sido que es intrínsecamente difícil de probar, por ejemplo, en ALT.Net Vote of No Confidence que se cita.
Aquí hay una publicación de blog que trata sobre 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 examinar otro marco ORM, como NHibernate, al menos hasta que se publique Entity Framework 2.0.
Estoy de acuerdo en que la versión 1 del 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 de ADO.NET que levantan banderas rojas brillantes. Veremos cómo funciona con el lanzamiento de .NET 4.0.
Sin embargo, parecen estar intentando:
Aunque la pregunta original ha sido respondida, siento que podría agregar 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 el POCO se puede 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 de tu objeto (el contexto del objeto básicamente funciona como una unidad incorporada) de trabajo para EF y es esencial para mapear tus objetos EF a POCO). Afortunadamente, Joachim Lykke Andersen en su blog Entity Framework 4.0 Beta 1 - POCO, ObjectSet, Repository y UnitOfWork escribió una plantilla t4 para generarla y fue 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 unidad de trabajo. Ha sido de mucha ayuda.
La mejor de las suertes.
Esta respuesta ha cambiado a "Sí, puedes".
Puede generar POCO e interfaces utilizando plantillas T4 personalizadas, como https://entityinterfacegenerator.codeplex.com/ , y luego crear objetos de burla para probar EF dentro y fuera sin tocar la base de datos.