¿Cómo hago TDD de manera eficiente con NHibernate?

Question

Me parece que la mayoría de las personas escribe sus pruebas en bases de datos en proceso y en proceso de la memoria, como SQLite, cuando trabaja con NHibernate. Lo tengo en funcionamiento pero mi primera prueba (que usa NHibernate) siempre lleva entre 3 y 4 segundos para ejecutarse. La próxima prueba se ejecuta mucho más rápido.

Estoy usando FluentNhibernate para hacer el mapeo pero obtengo aproximadamente los mismos tiempos con los archivos de mapeo XML. Para mí, la demora de 3-4 segundos interrumpe seriamente mi flujo.

¿Cuál es la forma recomendada de trabajar con TDD y NHibernate?

¿Es posible simular ISession para probar las consultas reales o solo se puede hacer esto en las bases de datos de la memoria?

Answer 1

Estoy usando el patrón de repositorio para realizar operaciones de base de datos, y cada vez que ejecuto mis pruebas solo ejecuto las pruebas de nivel superior que simulan simular el repositorio (con RhinoMocks).

Tengo un conjunto separado de pruebas que prueban explícitamente la capa Repository y las asignaciones de NHibernate. Y esos generalmente no cambian tanto como el negocio y la lógica GUI sobre ellos.

De esa manera obtener unittests muy rápidos que nunca se dio en el DB, y sigue siendo un capa DB bien probado

Answer 2

Ver http://www.autumnofagile.net y http://www.summerofnhibernate.com

Answer 3

Ha intentado cambiar algunos de los valores predeterminados de las propiedades de configuración opcionales? La desaceleración probablemente esté relacionada con ciertas optimizaciones que hace nhibernate con la generación de código.

http://nhibernate.info/doc/nh/en/index.html#configuration-optional

parece una db en la memoria va a ser la forma más rápida para poner a prueba una capa de sus datos. También parece que una vez que comienzas a probar tu capa de datos te mueves un poco más allá del ámbito de una prueba unitaria.

Answer 4

Unidad de acceso a datos de pruebas no es posible, pero usted puede probar la integración ella. Creo prueba de integración para mi acceso a datos en un proyecto separado de mis pruebas unitarias. Solo realizo las pruebas de integración (lentas) cuando cambio algo en los repositorios, el mapeo o el esquema de la base de datos. Debido a que las pruebas de integración no se mezclan con las pruebas unitarias, aún puedo ejecutar las pruebas unitarias aproximadamente 100 veces al día sin molestarme.