it-swarm.dev

¿Cómo hacer pruebas de unidad de base de datos?

He oído que al desarrollar una aplicación que utiliza una base de datos, debe hacer una prueba de unidad de base de datos. ¿Cuáles son las mejores prácticas en las pruebas unitarias de bases de datos? ¿Cuáles son las principales preocupaciones al hacer pruebas de unidad de db y cómo hacerlo "bien"?

42
juur

¿Cuáles son las mejores prácticas en las pruebas unitarias de bases de datos?

El marco DbUnit (un marco de prueba que permite poner una base de datos en un estado conocido y realizar afirmaciones contra su contenido) tiene una página que enumera las pruebas de base de datos mejores prácticas eso, para mi experiencia, son ciertas.

¿Cuáles son las principales preocupaciones al hacer pruebas de unidad db?

  • Crear un esquema actualizado, gestionar cambios de esquema
  • Configuración de datos (datos de referencia, datos de prueba) y mantenimiento datos de prueba
  • Manteniendo las pruebas independientes
  • Permitir a los desarrolladores trabajar simultáneamente
  • Velocidad (las pruebas que involucran bases de datos suelen ser más lentas y harán que toda la compilación tome más tiempo)

y como hacerlo "bien"?

Como se indicó, siga las buenas prácticas conocidas y use herramientas/marcos dedicados:

  • Preferir en la base de datos de memoria si es posible (para velocidad)
  • Usar un esquema por desarrollador es imprescindible (para permitir el trabajo concurrente)
  • Utilice una herramienta de "migración de base de datos" (à la RoR) para administrar los cambios de esquema y actualizar un esquema a la versión definitiva
  • Cree o use un arnés de prueba que permita poner la base de datos en un estado conocido antes de cada prueba y realizar afirmaciones contra los datos después de la ejecución (o ejecutar pruebas dentro de una transacción que revierte al final de la prueba).
37
Pascal Thivent

Una lista de elementos que deben revisarse y considerarse al mirar con pruebas de unidad de base de datos

  • Cada probador necesita una base de datos separada, para evitar interferir con las actividades de otro probador/desarrollador
  • Para tener una manera fácil de crear una base de datos para ser probada (esto está relacionado con tener una base de datos SQL Server bajo control de versiones). Esto es especialmente útil cuando se trata de encontrar lo que salió mal si algunas pruebas fallan
  • Concéntrese en áreas específicas y cree pruebas para un solo módulo en lugar de cubrir todas a la vez. Agregar pruebas de forma granular es una buena manera de ser eficiente
  • Asegúrese de proporcionar tantos detalles como sea posible cuando falle una prueba, para permitir una depuración más fácil
  • Utilice uno y los mismos datos de prueba para todas las pruebas

Si las pruebas se implementan utilizando el marco tSQLt, el proceso de prueba unitaria podría ser complicado cuando se manejan muchas bases de datos de múltiples instancias de SQL Server. Para mantener, ejecutar y administrar pruebas unitarias directamente desde SQL Server Management Studio, ApexSQL Unit Test puede usarse como una solución

12
MiWa

Echa un vistazo a este enlace . Repasa algunos de los conceptos básicos para crear pruebas unitarias almacenadas en SQL Server, así como los diferentes tipos de pruebas unitarias y cuándo debe usarlas. No estoy seguro de qué DBMS está utilizando, pero obviamente este artículo está dirigido a SQL Server.

Robado del artículo:

Pruebas de funciones

La primera y probablemente más frecuente clase de prueba de unidad de base de datos es una prueba de características. En mi opinión, las pruebas de características prueban las características principales (o API, si lo desea) de su base de datos desde la perspectiva del consumidor de la base de datos. Probar los objetos de programabilidad de una base de datos es el escenario principal aquí. Por lo tanto, probar todos los procedimientos almacenados, funciones y disparadores dentro de su base de datos constituyen pruebas de características en mi mente. Para probar un procedimiento almacenado, debe ejecutar el procedimiento almacenado y verificar que se hayan devuelto los resultados esperados o que haya ocurrido el comportamiento apropiado. Sin embargo, puede probar más que solo este tipo de objetos. Puede imaginar querer asegurarse de que una vista, por ejemplo, devuelva el cálculo apropiado de una columna calculada. Como puede ver, las posibilidades en este ámbito son grandes.

Pruebas de esquema

Uno de los aspectos más críticos de una base de datos es su esquema, y ​​las pruebas para garantizar que se comporta como se espera es otra clase importante de pruebas unitarias de bases de datos. Aquí, a menudo querrá asegurarse de que una vista devuelva el conjunto esperado de columnas del tipo de datos apropiado en el orden apropiado. Es posible que desee asegurarse de que su base de datos contenga, de hecho, las 1,000 tablas que espera.

Pruebas de seguridad

En la actualidad, la seguridad de los datos que se almacenan en la base de datos es crítica. Por lo tanto, otra clase importante de pruebas de unidad de base de datos son aquellas que prueban la seguridad de la base de datos. Aquí, querrá asegurarse de que existan usuarios particulares en su base de datos y que se les asignen los permisos apropiados. A menudo querrá crear pruebas negativas que intenten recuperar datos de tablas o vistas restringidas y asegurarse de que el acceso sea denegado adecuadamente.

Pruebas de datos de stock

Muchas bases de datos contienen datos de existencias o datos semilla. Estos datos cambian con poca frecuencia y a menudo se utilizan como datos de búsqueda para aplicaciones o usuarios finales. Los códigos postales y sus ciudades y estados asociados son excelentes ejemplos de este tipo de datos. Por lo tanto, es útil crear pruebas para garantizar que los datos de sus existencias, de hecho, existan en su base de datos.

10
Abe Miessler

Me alegra que hayas preguntado sobre las pruebas unitarias y no sobre las pruebas en general.

Las bases de datos tienen muchas características que necesitan ser probadas. Algunos ejemplos:

  • Tipos de datos/Tamaño/Conjuntos de caracteres (intente insertar un nombre sueco o urls o números largos del mundo real, y vea si las definiciones de sus columnas son correctas)
  • Disparadores
  • Contracciones (claves foráneas, unicidad ...)
  • Vistas (verifique que los datos estén correctamente incluidos/excluidos/transformados)
  • Procedimientos almacenados
  • UDF
  • Permisos
  • ...

Esto es útil no solo cuando cambia algo en su base de datos, sino también cuando actualiza sus dbms o cambia algo en su configuración.

En general, se realizan pruebas de integración. Esto significa que se crea un conjunto de pruebas en un lenguaje de programación como PHP o Java, y las pruebas emiten algunas consultas. Pero si algo falla, o hay algunas excepciones, es más difícil entender el problema, por 2 razones:

  • El problema podría estar en su código PHP, o en la configuración PHP, o en la red, o ...
  • Las declaraciones SQL son más difíciles de leer y modificar, si están incrustadas en otro lenguaje de programación.

Entonces, en mi opinión, para bases de datos complejas necesita usar un marco de Prueba de Unidad que está escrito en SQL (usando procedimientos y tablas almacenados). Debe elegirlo con cuidado, porque ese tipo de herramientas no se usa ampliamente (y, por lo tanto, no se prueba ampliamente). Por ejemplo, si usa MySQL, conozco estas herramientas:

4
Federico Razzoli

Uso junit/nunit/etc y codifico las pruebas unitarias de la base de datos con Java o c #. Estos pueden ejecutarse en un servidor de integración, quizás utilizando un esquema separado para la base de datos de prueba.

El último desarrollador de Oracle sql viene con un marco de prueba de unidad incorporado. Eché un vistazo a esto, pero NO lo usaría. Utiliza una GUI para crear y ejecutar pruebas y almacena todas las pruebas en la base de datos, por lo que no es tan fácil poner los casos de prueba bajo el control de versiones. Probablemente hay otros marcos de prueba por ahí, imagino que podrían ser específicos para su base de datos.

Las buenas prácticas son similares a las pruebas unitarias regulares:

  • poner las pruebas bajo control de fuente
  • haga pruebas que se ejecutan rápido, no pruebe demasiado de una vez
  • haz que tus pruebas sean reproducibles
3
Adam Butler

Eche un vistazo al marco DBTestDriven. Funciona muy bien para nosotros. Descárguelo de GitHub o de su sitio web.

2
Oleksandr

En cuanto al desarrollo de JVM, las pruebas unitarias pueden beneficiarse de la abstracción JDBC: tan pronto como sepa qué datos JDBC se generan mediante el acceso a la base de datos, estos datos JDBC se pueden "reproducir".

Por lo tanto, el caso de acceso a la base de datos puede "reproducirse" para la prueba, sin la base de datos de destino: sin complejidad de prueba/aislamiento de datos, facilita la integración continua.

Mi marco Acolyte es un marco útil de esta manera (incluida la herramienta GUI de estudio para 'grabar' el resultado de la base de datos): https://github.com/cchantep/acolyte

1
cchantep