database - con - ¿Cómo hacer pruebas de unidad de base de datos?

pruebas de php (7)

He oído que cuando se desarrolla 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 de unidad de base de datos? ¿Cuáles son las principales preocupaciones cuando se realizan pruebas de unidad de db y cómo hacerlo "bien"?

¿Cuáles son las mejores prácticas en las pruebas de unidad de base de datos?

El marco DbUnit (un marco de prueba que permite colocar una base de datos en un estado de conocimiento y realizar afirmaciones contra su contenido) tiene una página que enumera las mejores prácticas de prueba de la base de datos que, según mi experiencia, son ciertas.

¿Cuáles son las principales preocupaciones cuando se realizan pruebas de unidad de db?

Crear un esquema actualizado, administrar cambios de esquema
Configuración de datos (datos de referencia, datos de prueba) y mantenimiento de datos de prueba
Manteniendo las pruebas independientes
Permitir que los desarrolladores trabajen al mismo tiempo
Velocidad (las pruebas que involucran a la base de datos son generalmente más lentas y harán que toda tu construcción tome más tiempo)

y cómo hacerlo "bien"?

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

Preferir en la base de datos de memoria si es posible (por velocidad)
Usar un esquema por desarrollador es imprescindible (para permitir el trabajo simultáneo)
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 que realice afirmaciones contra los datos después de la ejecución (o para ejecutar pruebas dentro de una transacción que restituya al final de la prueba).

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

Robado del artículo:

Pruebas de funciones
La primera y 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 se quiere) 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, funciones y desencadenantes almacenados en su base de datos constituyen pruebas de funciones en mi mente. Para probar un procedimiento almacenado, debe ejecutar el procedimiento almacenado y verificar que se devolvieron los resultados esperados o que se produjo el comportamiento apropiado. Sin embargo, puedes probar más que solo este tipo de objetos. Puede imaginar que desea garantizar 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 asegurar que se comporte como se espera es otra clase importante de pruebas de unidades de base 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, de hecho, contenga 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 unidades de base de datos son aquellas que prueban la seguridad de la base de datos. Aquí, querrá asegurarse de que existen usuarios particulares en su base de datos y que se les hayan asignado los permisos adecuados. A menudo querrá crear pruebas negativas que intenten recuperar datos de tablas o vistas restringidas y garantizar que el acceso sea denegado de manera apropiada.
Pruebas de Stock-Data
Muchas bases de datos contienen datos de existencias, o datos iniciales. 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 sus datos de inventario, de hecho, existan en su base de datos.

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

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

Por lo tanto, el caso de acceso a la base de datos se puede ''reproducir'' para probar, sin la base de datos de destino: sin complejidad de aislamiento de prueba / datos, facilidad de integración continua.

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

Me alegra que hayas preguntado acerca de Unit Testing y no pruebas en general.

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

Tipos de datos / Tamaño / Conjunto de caracteres (intente insertar un nombre sueco, o largas URL o números de los mundos reales, y vea si las definiciones de sus columnas son correctas)
Disparadores
Contraints (claves externas, singularidad ...)
Vistas (verifique que los datos estén correctamente incluidos / excluidos / transformados)
Procedimientos almacenados
UDFs
Permisos
...

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

En general, se realizan pruebas de integración. Esto significa que se crea un Test Suite 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 dos razones:

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

Por lo tanto, en mi opinión, para las bases de datos complejas, debe usar un marco de prueba de unidades que está escrito en SQL (usando procedimientos y tablas almacenadas). Tienes que elegirlo con cuidado, porque ese tipo de herramientas no se usan ampliamente (y por lo tanto no se prueban ampliamente). Por ejemplo, si usa MySQL, conozco estas herramientas:

STK / Unidad http://stk.wikidot.com/stk-unit
utMySQL http://utmysql.sourceforge.net/

Una lista de elementos que deben ser revisados y considerados cuando se mira 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
Tener una forma fácil de crear una base de datos para probar (esto está relacionado con tener una base de datos SQL Server bajo control de versión). Esto es especialmente útil cuando se trata de encontrar lo que salió mal si algunas pruebas fallan
Céntrese en áreas específicas y cree pruebas para un solo módulo en lugar de cubrir todas a la vez. Agregar pruebas granularmente es una buena forma de ser eficiente
Asegúrese de proporcionar tantos detalles como sea posible cuando falla una prueba, para permitir una depuración más sencilla
Use uno y el mismo dato de prueba para todas las pruebas

Si las pruebas se implementan utilizando tSQLt framework, el proceso de prueba de la unidad podría ser complicado cuando se trata de una gran cantidad de bases de datos de múltiples instancias de SQL Server. Para poder mantener, ejecutar y administrar pruebas unitarias directamente desde SQL Server Management Studio, ApexSQL Unit Test se puede usar como una solución

Utilizo junit / nunit / etc y codigo las pruebas de unidad de base de datos con java o c #. Estos pueden ejecutarse en un servidor de integración tal vez utilizando un esquema separado para la base de datos de prueba.

El último desarrollador de Oracle sql viene con un marco de prueba integrado de la unidad. 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 casos de prueba bajo control de versión. Probablemente existan otros marcos de prueba, imagino que podrían ser específicos de su base de datos.

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

poner las pruebas bajo el control de la fuente
haga pruebas que corran rápido, no haga demasiadas pruebas a la vez
haz tus pruebas reproducibles