Cuando se realizan pruebas unitarias, ¿es obligatorio usar una base de datos cuando se prueban las operaciones CRUD? ¿Puede sql lite ayudar con esto? ¿Tiene que crear de nuevo el db de alguna manera en la memoria?Cuando se realizan pruebas unitarias, ¿tiene que usar una base de datos para probar las operaciones CRUD?
Estoy usando mbunit.
No. La integración de una base de datos real sería prueba de integración. No pruebas unitarias
Sí se podría utilizar cualquier base de datos en memoria como SQLite o MS SQL compacto para esto si no se puede abstracta (simulado) de su DAL/DAO en cualquier otra forma.
Con esto en mente, tengo que señalar que pruebas de unidad es posible hasta DAL, pero no DAL en sí. DAL tendrá que probarse con algún tipo de DB real en las pruebas de integración.
Realmente, si está escribiendo una prueba que se conecta a una base de datos, está haciendo las pruebas de integración , pruebas no unitarias.
Para la prueba unitaria de tales operaciones, considere usar algún tipo de objeto de base de datos falsa. Por ejemplo, si tiene una clase que encapsula su interacción con la base de datos, extraiga una interfaz de la misma y luego cree una clase heredada que use objetos simples en memoria en lugar de conectarse a la base de datos.
pero ¿cómo se puede probar una inserción o una eliminación? ¡Simplemente no entiendo! – mrblah
@homestead: la prueba unitaria debe probar solo una cierta UNIDAD de código, no un proceso comercial completo. –
@homestead: Escribe una prueba de integración para ello. – JoshJordan
Al igual que con todas pregunta complicada, la respuesta es: depende :)
En general, usted debe ocultar su capa de acceso de datos detrás de una interfaz para que pueda probar el resto de la aplicación sin necesidad de utilizar una base de datos, pero ¿y si le gustaría probar la implementación del acceso a datos en sí?
En algunos casos, algunas personas consideran que esto es redundante ya que en su mayoría usan tecnologías de acceso a datos declarativos como ORM.
En otros casos, el componente de acceso a datos puede contener cierta lógica que puede querer probar. Eso puede ser algo completamente relevante, pero necesitará la base de datos para hacerlo.
Algunas personas consideran que se trata de Pruebas de integración en lugar de Pruebas unitarias, pero en mi libro, no importa demasiado cómo lo llames, lo más importante es que obtienes valor de tus pruebas totalmente automatizadas, y definitivamente puede usar un marco de prueba unitario para conducir esas pruebas.
Hace un tiempo escribí sobre how to do this on SQL Server. Lo más importante a tener en cuenta es evitar la tentación de crear un dispositivo general con algunos "datos representativos" e intentar reutilizarlo en todas las pruebas. En su lugar, debe completar los datos como parte de cada prueba y limpiarlos después.
+1. Creo que lo has clavado :) – si618
Cuando se realizan pruebas unitarias, ¿es obligatorio utilizar una base de datos cuando se prueban las operaciones CRUD?
Asumiendo por un momento que ha extraído interfaces alrededor de dichas operaciones CRUD y ha probado todo lo que utiliza dicha interfaz a través de simulaciones o talones. Ahora se queda con un fragmento de código que es un método de guardar que contiene un poco de código para enlazar objetos y algo de SQL.
Si es así, declararía una "Unidad" y diría que necesita una base de datos, e idealmente una que sea al menos una buena representación de su base de datos, no sea que se vea atrapado con SQL específico del vendedor.
también me gustaría hacer uso de la luz de burla con el fin de obligar a las condiciones de error, pero no me gustaría probar el método salvarse con sólo burla. Entonces, aunque técnicamente esto puede ser una prueba de integración, aún lo haría como parte de mis pruebas unitarias.
Editar: Fallecieron 2/3s de tu pregunta. Lo siento.
Cómo SQL Lite ayuda con esto?
En el pasado, he usado bases de datos de memoria y me han mordido ya sea porque la base de datos que utilicé y el sistema en vivo hicieron algo diferente o tardaron bastante en iniciarse. Yo recomendaría que cada desarrollador tenga una base de datos local de desarrolladores de todos modos.
¿Tiene que cre-crear la base de datos de alguna manera en la memoria?
En la base de datos sí. Utilizo DbUnit para salpicar datos y mantener manualmente el esquema actualizado con las secuencias de comandos de SQL, pero podría utilizar solo las secuencias de comandos SQL. Tener una base de datos local de desarrollador agrega algo de mantenimiento adicional ya que tiene tanto el esquema como los conjuntos de datos para mantener los datos, pero personalmente considero que vale la pena ya que puede estar seguro de que la capa de la base de datos está funcionando como se esperaba.
Como ya han señalado otros, lo que está tratando de lograr no son las pruebas unitarias sino las de integración.
Habiendo dicho esto, y aunque yo prefiero las pruebas unitarias en forma aislada con burla, no hay nada realmente mal con las pruebas de integración. Entonces, si cree que tiene sentido en su contexto, solo incluya las pruebas de integración en su estrategia de prueba.
Ahora, con respecto a su pregunta, echaría un vistazo DbUnit.NET. No conozco la versión .NET de esta herramienta, pero puedo decirle que la versión de Java es excelente para las pruebas que interactúan con una base de datos. En pocas palabras, DbUnit le permite colocar la base de datos en un estado conocido antes de ejecutar una prueba y realizar afirmaciones sobre el contenido de las tablas. Muy útil. Por cierto, recomendaría leer la página Best Practices, incluso si decide no utilizar esta herramienta.
Como se mencionó anteriormente, la clave aquí es tener su base de datos de prueba en un estado conocido antes de ejecutar las pruebas. En un ejemplo del mundo real, tengo un par de scripts SQL que se ejecutan antes de las pruebas que recrean un conjunto conocido de datos de prueba. A partir de esto, puedo probar las operaciones CRUD y verificar que las nuevas filas estén insertadas/actualizadas/eliminadas.
Escribí una utilidad llamada DBSnapshot para ayudar prueba de integración bases de datos sqlserver.
Si su esquema de base de datos está cambiando con frecuencia, será útil probar realmente el código en una instancia de db real. La gente usa SqlLite para realizar pruebas rápidas (porque la base de datos se ejecuta en la memoria), pero esto no es útil cuando quiere verificar que su código funciona en contra de una compilación real de su base de datos.
Al probar su base de datos que desea seguir un patrón similar a: copia de seguridad de la base de datos, la configuración de la base de datos para una prueba, ejercer el código, verificar los resultados, restaurar la base de datos al estado inicial.
Lo anterior garantizará que pueda ejecutar cada prueba de forma aislada. Mi utilidad DBSnapshot simplificará su código si está escribiendo .net. Creo que es más fácil de usar que DbUnit.NET.
Reconociendo el hecho de que en realidad es una prueba de integración, ¿hay algún valor para falsificar una base de datos para realizar las pruebas unitarias? –
Sí lo es. Le ayudaría a probar sus repositorios de datos, que usan DAL (en este caso, burlados). –
-1. Creo que la respuesta de Mark es más precisa: depende porque si estás escribiendo código que persiste datos en nombre de otro código (n-tier, biblioteca de frameworks, etc.), entonces una prueba unitaria es exactamente eso, probando que una unidad en particular de código está funcionando como se esperaba. Por ejemplo, supongamos que utiliza columnas de IDENTIDAD en su base de datos y devuelve el ID creado como una consulta SELECT después de un INSERT, este código debe ser unitario probado, es decir, se espera que el valor de retorno sea el ID esperado. Estoy de acuerdo en que crear repositorios simulados es bueno, pero hay algunas cosas de las que no te puedes burlar. – si618