DBMS en memoria para pruebas unitarias

Question

Estoy buscando opciones satisfactorias para las pruebas unitarias de mis clases .NET DAL; Como son clases DAL, acceden a la base de datos directamente mediante ADO.NET. Actualmente utilizo una instancia de una base de datos MSSQL para las pruebas, pero me preguntaba qué opciones más rápidas hay --- dado que las pruebas unitarias deben ejecutarse lo más rápido posible, una solución en memoria sería ideal.

También debo mencionar que me he atado a TSQL ya que solo voy a usar una plataforma de Microsoft.

Answer 1

Dado que usted declara:

  

También debo mencionar que he atado   yo mismo a TSQL ya que solo estoy   va a estar usando un Microsoft   plataforma.

Entonces, usar SqlServer compact Edition puede funcionar bien para sus necesidades. No funcionará completamente en la memoria, pero puede funcionar en modo de solo lectura (donde no se producen modificaciones en el archivo de la base de datos principal, por lo que puede ser utilizado por múltiples pruebas a la vez)

Hay algunas trampas, no se admiten procedimientos almacenados, es necesario traducir algunos tipos de datos y ciertos tipos de datos tienen límites estrictos (especialmente varchar que solo puede llegar a 4000 caracteres) Linq a Sql tampoco es compatible.

No obstante, he usado un SqlServer Compact Edition como un reemplazo casi total de la base de datos del servidor Sql con buenos resultados.

Answer 2

He encontrado que SQLite es la mejor opción. Sin embargo, estoy usando nHibernate, pero es cero configuración, por lo que solo toma un segundo configurarlo. Sin embargo, debe tener en cuenta que estos tipos de motores generalmente carecen de algunas cosas que podría necesitar (por ejemplo, SQLite explota cuando tiene espacios en los nombres de las tablas si está utilizando un proveedor ADO)

De acuerdo, @TopBanana tiene razón acerca de algunos de los problemas al no usar un " real " base de datos. Sin embargo, un RDBMS en memoria es perfecto para ese tipo de pruebas que desea ejecutar muy rápidamente (por ejemplo, pruebas de verificación para compilaciones incrementales o de CI).

La otra gran ventaja es que no tiene que preocuparse por la instalación o la destrucción. Es increíblemente improductivo que su registro falle porque el desarrollador A rompió su base de datos de desarrollo ;-)

Answer 3

Recomendaría usar la misma base de datos para las pruebas unitarias que para la producción. Realmente no necesitas alguna diferencia extraña disparándote en el pie cuando estás depurando un problema en vivo.

Si observa el conjunto de pruebas de unidad realmente grande para NHibernate, verá que usa SQL Server (basado en disco), y las pruebas se ejecutan sorprendentemente rápido. Es aún más impresionante tener en cuenta que hay mucha más creación / eliminación de tablas que el conjunto promedio de pruebas unitarias, que no es para lo que SQL Server está optimizado.

Answer 4

Escuché que hay un software para montar ramdisk en Windows (no recuerdo la URL, lo siento).

Podría ser interesante crear bases de datos de prueba sobre eso.

Answer 5

¿Es SQL Server realmente el cuello de botella para sus pruebas unitarias?

Quiero decir:

1. ¿Ha perfilado sus pruebas unitarias (con algo como SQL Profiler). ¿Son todos lentos? ¿Son algunos lentos? ¿Por qué?
2. ¿Sus pruebas unitarias están haciendo demasiado? ¿El código de instalación y desmontaje es demasiado pesado?
3. Si SQL es su cuello de botella, ¿ha considerado un marco de imitación , de modo que burlarse de todas sus llamadas SQL.

Answer 6

Tuve desafíos similares con Oracle e hicimos lo siguiente:

• se aseguró de que tuviéramos que las pruebas unitarias reales no tocaban la base de datos, sino que usaban simulacros para los servicios

• Pruebas de bases de datos etiquetadas que realmente necesitaban Oracle en comparación con las pruebas que podían ejecutarse contra HSQLDB o H2 o cualquier otra en la base de datos de memoria. Entonces podemos ejecutarlos por separado.

• Con las pruebas que realmente usaron las características de Oracle, usamos una instancia normal de Oracle que se ejecutó en un disco RAM.

Esto hizo que las pruebas fueran considerablemente más rápidas.