database - para - optimización de consultas bases datos
¿Qué mejores prácticas usa para probar las consultas de la base de datos? (8)
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 testers realizaban pruebas de consulta de forma manual creando 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, ordenando, qué es lo que tienes.
Esto tuvo el efecto secundario de que los errores se archivaran contra la consulta del verificador con más frecuencia que contra la consulta real en cuestión.
Propuse realmente trabajar con un conjunto de resultados conocido que podría deducir cómo debería volver, ya que controla los datos presentes; anteriormente, los datos se extraían de la producción, se desinfectaban y luego se llenaban en nuestras bases de datos de prueba.
Las personas seguían insistiendo en crear sus propias consultas para probar lo que los desarrolladores habían creado. Sospecho que muchos todavía lo están. Tengo en mente que esto no es ideal en absoluto, y solo aumenta nuestra huella de prueba innecesariamente.
Entonces, tengo curiosidad, ¿qué prácticas usas para probar escenarios como este, y qué se consideraría ideal para obtener la mejor cobertura de extremo a extremo que puedas obtener, sin introducir datos caóticos?
El problema que tengo es dónde es el mejor lugar para hacer qué pruebas. ¿Solo meto el servicio directamente y comparo ese conjunto de datos con el que puedo extraer del procedimiento almacenado? Tengo una idea aproximada, y he tenido éxito hasta ahora, pero siento que todavía nos falta algo importante aquí, por lo que estoy buscando a la comunidad para ver si tienen alguna información valiosa que pueda ayudar a formular mi enfoque de prueba. mejor.
Aquí hay algunas pautas:
- Utilice una base de datos aislada para pruebas unitarias (p. Ej., Ninguna otra ejecución de prueba o actividad)
- Siempre inserte todos los datos de prueba que desea consultar dentro de la misma prueba
- Escriba las pruebas para crear aleatoriamente diferentes volúmenes de datos, por ejemplo, el número aleatorio de insertos dice entre 1 y 10 filas
- Aleatorizar los datos, por ejemplo, para un campo booleano inserción aleatoria y verdadero o falso
- Mantenga un conteo en la prueba de las variables (por ejemplo, número de filas, número de trues)
- Para que Asserts ejecute la consulta y compare contra las variables de prueba locales
- Utilice las transacciones de servicios de empresa para restaurar la base de datos al estado anterior
Vea el siguiente enlace para la técnica de Transacción de Servicios de Empresas:
http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx
Como parte de nuestra integración continua, ejecutamos nuestra "creación" nocturna de las consultas de la base de datos. Esto implica un conjunto de llamadas a bases de datos 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 toman demasiado tiempo.
2 / No difieren mucho (en mal modo) de la noche anterior.
De esta forma, detectamos las consultas errantes o los cambios en la base de datos rápidamente.
Probar procs almacenados requerirá que cada persona que realice la prueba 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 deberá asegurarse de revertir el DB 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 llevarán mucho más tiempo para completar que las pruebas unitarias estándar, por lo que probablemente sean algo que desea ejecutar durante la noche.
Hay algunas herramientas para ayudarlo con esto. DbUnit es uno de ellos y también creo que Microsoft tenía una herramienta Visual Studio para Database Professionals que contenía algo de soporte para las pruebas DB.
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 TestCase estándar de TestCase de Python que rellena 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 completar la base de datos a partir de un extracto de datos JSON. Otros formatos de archivo para el dispositivo se pueden usar para otros marcos. Por ejemplo, si está trabajando en Oracle, puede que le resulte más fácil trabajar con archivos CSV.
Esta subclase TestCase permite escribir un TestCase de aspecto típico que ejercita la base de datos con el accesorio 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 lo tiene disponible, igual necesitará el script DDL para que pueda crear y deshacerse de un esquema de prueba para fines de prueba de unidad.
El planificador de consultas es tu amigo, especialmente en este caso. Siempre es una buena práctica verificar que los índices se utilicen cuando usted los espera y que la consulta no requiere un trabajo adicional. Incluso si tiene pruebas de estrés incluidas en su suite, es una buena idea buscar consultas costosas antes de que su aplicación comience a detenerse.
Me parece ú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 parece mucho más rápido probarlo que tener demasiado levantada la base de datos.
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 - verificar que el resultado real sea igual al resultado esperado
Desmontaje: devuelve todo a la forma en que estaba antes de que comenzara la prueba. En realidad, esto se hace invirtiendo una transacción, lo que mantiene todo ordenado y ordenado.
Aunque no lo he usado, parece prometedor y ciertamente lo analizaré con más detalle.
El marco se puede descargar aquí .
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.
A continuación, podemos probar varios escenarios diferentes en el mismo DB (uno después del otro) y nunca estampamos en los dedos de otros probadores.
Eso cubre probar el acceso a los datos en sí mismo. Para las pruebas de servicio, hacemos más o menos lo mismo, pero solo probamos el interior del servicio: en realidad, no damos en el 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.)