Entity Framework 4.0 Unit Testing

Question

Implementé pruebas unitarias siguiendo las líneas de este artículo con un contexto de objeto falso e IObjectSet con POCO en EF4.

http://blogs.msdn.com/adonet/archive/2009/12/17/test-driven-development-walkthrough-with-the-entity-framework-4-0.aspx

Pero estoy seguro de cómo poner en práctica un par de métodos en mi contexto del objeto falsa para la prueba. Tengo métodos CreateQuery y ExecuteFunction en mi interfaz de contexto de objetos para poder ejecutar ESQL y procedimientos almacenados, pero no puedo implementarlos (fácilmente) en mi contexto de objeto falso.

Una alternativa sería utilizar una doble prueba de mi repositorio en lugar de un doble de mi contexto del objeto como se sugiere aquí:

http://social.msdn.microsoft.com/Forums/en-US/adonetefx/thread/c4921443-e8a3-4414-92dd-eba1480a07ad/

Pero esto significaría mi isnt real del repositorio siendo probado y parece para eludir el problema.

¿Alguien puede ofrecer alguna recomendación?

Answer 1

Por lo que yo puedo decir de la cuestión, que están tratando de probar demasiado al mismo tiempo. Mantenga el Single Responsibility Principle en mente.

Cuando prueba de unidad, utilizamos repositorios abstractos para abstraer el código de acceso a datos de distancia del resto de la aplicación. Desde esta perspectiva, solo estamos probando los consumidores de los repositorios, no en ningún depósito concreto. Tales consumidores deben cuidar solamente sobre los repositorios, y en absoluto acerca de cualquier 'contexto del objeto' - que sería un Leaky Abstracción.

Imagínese que le están dando de forma inesperada para conectar sus consumidores repositorio hasta una capa de datos completamente diferente (por ejemplo, un servicio basado en REST). En tales casos, incluso un contexto de objeto abstracto no tiene sentido. Es posible que nunca esperes que esto suceda, pero aun así, el experimento mental por sí solo es un indicador bastante bueno de una Abstracción furtiva.

El contexto del objeto es un detalle de implementación de su implementación concreta de Repositorio que utiliza EF. Otras implementaciones pueden no necesitar un contexto de objeto en absoluto.

Dicho esto, es posible que desee probar la implementación de EF en sí. Eso puede tener mucho sentido, pero esa es una suite de pruebas de unidad diferente con un propósito completamente diferente. En lugar de probar a los consumidores de sus Repositorios abstractos, ahora está probando una implementación concreta de un Repositorio. En este caso, no es necesario pasar por las interfaces; aquí puede hablar directamente con los tipos concretos.

Answer 2

¿Es posible probar los Repositorios reales con una base de datos en memoria como SQLite? Existe un proveedor de SQLite para Entity Framework.

Parece que la sección SSDL en el archivo edmx está acoplada a un proveedor. Si genera el modelo desde una base de datos Sql-server, se establecerá el proveedor = "System.Data.SqlClient". Esto también se establecerá si genera una base de datos sql-server a partir de un modelo de entidad.

Lo que realmente me gustaría es hacer que el profesional de la utilización System.Data.SqlClient código de producción y mis pruebas de unidad para utilizar el proveedor System.Data.SqLite.