¿Qué mejores prácticas utiliza para probar las consultas de la base de datos?

Question

Actualmente estoy en el proceso de probar nuestra solución que tiene toda la "gama". de capas: UI, Middle y la base de datos omnipresente.

Antes de mi llegada a mi equipo actual, los evaluadores realizaron pruebas de consultas para elaborar manualmente las consultas que teóricamente devolverían un conjunto de resultados que el procedimiento almacenado debería devolver en función de varias reglas de relevancia, clasificación, lo que sea.

Esto tuvo el efecto secundario de que los errores se archivaran en la consulta del probador con más frecuencia que en la consulta real en cuestión.

Propuse trabajar en realidad con un conjunto de resultados conocido que simplemente podría inferir cómo debería regresar, ya que controla los datos presentes; anteriormente, los datos se extraían de la producción, se desinfectaban y luego se rellenaban en nuestras bases de datos de prueba.

La gente seguía insistiendo en crear sus propias consultas para probar lo que los desarrolladores habían creado. Sospecho que muchos todavía lo son. Tengo en mente que esto no es ideal en absoluto, y solo aumenta nuestra huella de pruebas innecesariamente.

Entonces, tengo curiosidad, ¿qué prácticas utiliza para probar escenarios como este, y qué se consideraría ideal para la mejor cobertura de extremo a extremo que puede obtener, sin introducir datos caóticos?

El problema que tengo es dónde está el mejor lugar para hacer qué pruebas. ¿Acabo de introducir el servicio directamente y comparar ese conjunto de datos con el que puedo extraer del procedimiento almacenado? Tengo una idea aproximada y hasta ahora he tenido el éxito suficiente, pero siento que todavía nos falta algo importante aquí, así que estoy mirando a la comunidad para ver si tienen alguna información valiosa que pueda ayudar a formular mi enfoque de prueba. mejor.

Answer 1

La prueba de los procesos almacenados requerirá que cada persona que pruebe tenga una instancia separada de la base de datos. Este es un requisito. Si comparte entornos, no podrá confiar en los resultados de su prueba. Serán inútiles.

También tendrá que asegurarse de revertir la base de datos a su estado anterior después de cada prueba para que los resultados sean predecibles y estables. Debido a esta necesidad de revertir el estado después de cada prueba, estas pruebas tardarán mucho más en completarse que las pruebas unitarias estándar, por lo que probablemente sean algo que desee ejecutar durante la noche.

Existen algunas herramientas para ayudarlo con esto. DbUnit es uno de ellos y también creo que Microsoft tenía una herramienta Visual Studio para profesionales de bases de datos que contenía algo de soporte para las pruebas de base de datos.

Answer 2

Aquí hay algunas pautas:

1. Use una base de datos aislada para las pruebas unitarias (por ejemplo, ninguna otra prueba o actividad)
2. Siempre inserte todos los datos de prueba que desea consultar dentro de la misma prueba
3. Escriba las pruebas para crear aleatoriamente diferentes volúmenes de datos, p. número aleatorio de inserciones dice entre 1 y 10 filas
4. Aleatorizar los datos, p. para una inserción aleatoria de campo booleano y verdadero o falso
5. Mantenga un recuento en la prueba de las variables (por ejemplo, número de filas, número de verdades)
6. Para la consulta Ejecutar consulta y comparar con variables de prueba locales
7. Usar transacciones de Servicios empresariales para revertir la base de datos al estado anterior

Consulte el siguiente enlace para ver la técnica de Transacción de servicios empresariales:

http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

Answer 3

Como parte de nuestra integración continua, ejecutamos nuestra "compilación" nocturna de las consultas de la base de datos. Esto implica un conjunto de llamadas DB que se actualizan regularmente a partir de las llamadas reales en el código, así como cualquier consulta ad-hoc esperada.

Estas llamadas están programadas para garantizar que:

1 / No tardan demasiado.

2 / No difieren mucho (de mala manera) de la noche anterior.

De esta forma, detectamos consultas errantes o cambios en la base de datos rápidamente.

Answer 4

El planificador de consultas es tu amigo, especialmente en este caso. Siempre es una buena práctica verificar si los índices se usan cuando se espera que sean y que la consulta no requiera un trabajo adicional. Incluso si tiene pruebas de estrés incluidas en su suite, es una buena idea tomar consultas costosas antes de que su aplicación comience a detenerse.

Answer 5

Tenemos una base de datos en blanco reservada para cada desarrollador y probador.

Cuando se ejecutan las pruebas, cada prueba borra la base de datos y carga los datos que espera usar. Esto nos da un estado conocido en todo momento.

Entonces podemos probar varios escenarios diferentes en el mismo DB (uno tras otro) y nunca estampamos en los dedos de los demás probadores.

Eso cubre probar el acceso a los datos en sí. Para las pruebas de servicio, hacemos casi lo mismo, pero probamos solo el interior del servicio: en realidad no accedimos al servicio, creamos una instancia de la clase de procesamiento del servicio y pasamos todo lo que necesitamos. De esa forma, estamos probando el código y no la infraestructura (mensaje, etc.)

Answer 6

Django ofrece una capacidad de prueba de unidad de base de datos. Puede tomar prestadas sus ideas de diseño y reproducirlas en otros entornos.

La gente de Django ofrece una subclase de la clase de prueba estándar de Python TestCase que puebla una base de datos con un dispositivo conocido: un conjunto conocido de filas de datos.

En el caso de Django (y Python) es más fácil poblar la base de datos a partir de un extracto de datos JSON. Se pueden usar otros formatos de archivo para el dispositivo para otros marcos. Por ejemplo, si está trabajando en Oracle, puede encontrar archivos CSV más fáciles de trabajar.

Esta subclase TestCase permite escribir un TestCase de aspecto típico que ejercita la base de datos con el dispositivo de datos conocido.

Además, el corredor de prueba de Django crea un esquema temporal para fines de prueba. Esto es fácil para Django porque tienen un componente completo de gestión relacional de objetos que incluye la creación de DDL. Si no tiene esto disponible, aún necesitará el script DDL para poder crear y disponer de un esquema de prueba para propósitos de prueba de unidad.

Answer 7

SQLServerCentral tiene un artículo aquí (puede que tenga que registrarse pero es gratis y sin cadenas) sobre un marco de prueba de unidad TSQL llamado tsqlUnit. Es de código abierto y sigue la tradición del marco xUnit.

Sigue el patrón SEAT TDD:

Configuración: prepare las condiciones de prueba manipulando los objetos, tablas y / o datos

Ejercicio: invocar el código de producción

Afirmar: compruebe que el resultado real es igual al resultado esperado

Desmontaje: devuelva todo a la forma en que estaba antes de que comenzara la prueba. En realidad, esto se hace al deshacer una transacción, lo que mantiene todo bien y ordenado.

Aunque no lo he usado, parece prometedor y ciertamente es algo que analizaré con más detalle.

El marco se puede descargar aquí .

Answer 8

Encuentro útil probar el SQL que se envía a la base de datos en lugar del resultado de consultar la base de datos.

No es que no lo haga más tarde, pero me resulta mucho más rápido probar eso que tener la base de datos demasiado levantada.

Answer 9

Esta es una configuración pesada, pero recomiendo los contenedores TDDing.

Al ejecutar su script de prueba, cree un nuevo contenedor que tenga su base de datos ejecutándose en su interior, siembre con datos simulados, luego ejecute las consultas y pruebe lo que se devolvió y si las consultas fueron exitosas o no.

De esta manera usted tiene control sobre qué tan cerca de la producción está su entorno de prueba.

ThoughtWorks