sql >> Base de Datos >  >> RDS >> Oracle

Cómo probar (unitariamente) una aplicación PL/SQL con uso intensivo de datos

Existen varias herramientas de prueba diferentes para PL/SQL. Steven Feuerstein ha escrito dos de ellos, utplsql y Probador de código Quest para Oracle (anteriormente QUTE). Soy un gran admirador de utplsql, pero ya no tiene una comunidad de soporte activa (lo cual es una pena). También tiende a ser bastante detallado, especialmente cuando se trata de configurar dispositivos de prueba. Tiene el virtual cardinal de ser paquetes PL/SQL puros; el código fuente es un poco retorcido pero es FOSS.

QCTO viene con una GUI, lo que significa que, al igual que otros productos de Quest, es decir, TOAD, es solo para Windows. No automatiza exactamente la generación de datos de prueba, pero proporciona una interfaz para respaldarla. Al igual que otros productos de Quest, QCTO tiene licencia, aunque existe una copia gratuita.

Steven (divulgación, él es uno de mis héroes de Oracle) ha escrito una comparación de características de todas las herramientas de prueba de PL/SQL. Obviamente, QOTC sale a la cabeza, pero creo que la comparación es honesta. Échale un vistazo.

Consejos sobre dispositivos de prueba en utplsql

Administrar datos de prueba para pruebas unitarias puede ser un verdadero dolor de cabeza. Desafortunadamente, utplsql no ofrece mucho para asumir la carga. Entonces

  • Pruebe siempre contra valores conocidos :<último>
  • Evite usar dbms_random;
  • Intente restringir el uso de secuencias a columnas cuyos valores no importen;
  • Las fechas también son complicadas. Evite la codificación de fechas:use variables que se completen con sysdate. Aprende a apreciar add_months() , last_day() , interval , trunc(sysdate, 'MM') , etc.
  • Aísle los datos de prueba de otros usuarios. Constrúyelo desde cero. Utilice valores distintivos siempre que sea posible.
  • Cree solo la cantidad de datos de prueba que necesite. Las pruebas volumétricas son una responsabilidad diferente.
  • Al probar procedimientos que modifican los datos, cree registros específicos para cada prueba unitaria.
  • Además:no confíe en el resultado exitoso de una prueba para proporcionar la entrada de otra prueba.
  • Cuando se prueban procedimientos que simplemente se comparan con datos, se comparten registros entre pruebas unitarias cuando corresponde.
  • Comparta datos del marco (por ejemplo, claves principales referenciadas) siempre que sea posible.
  • Utilice campos de texto libre (nombres, descripciones, comentarios) para identificar qué prueba o pruebas utilizan el registro.
  • Minimice el trabajo que implica la creación de nuevos registros:
    • Solo asigne valores que sean necesarios para el conjunto de pruebas y las restricciones de la tabla;
    • Utilice valores predeterminados tanto como sea posible;
    • Proceduralice tanto como sea posible.

    • Otras cosas a tener en cuenta:

    • La configuración de un dispositivo de prueba puede ser un ejercicio que requiere mucho tiempo. Si tiene muchos datos, considere crear un procedimiento para configurar los datos estáticos que se pueden ejecutar una vez por sesión e incluya solo datos volátiles en ut_setup sí mismo. Esto es especialmente útil cuando se prueba la funcionalidad de solo lectura.
    • recuerde que la creación de datos de prueba es un ejercicio de programación por derecho propio y, por lo tanto, propenso a errores.
    • usar todas las características de utplsql. utAssert.EqQuery , utAssert.EqQueryValue , utAssert.EqTable , utAssert.EqTabCount y utAssert.Eq_RefC_Query son características muy útiles cuando se trata de inferir los valores de los datos volátiles.
    • al diagnosticar una ejecución de prueba que no salió como esperábamos, puede ser útil tener los datos que se usaron. Así que considera tener un hueco ut_teardown procedimiento y borrar los datos de prueba al comienzo de ut_setup .

    Tratar con código heredado

    Comentar la publicación de Gary me recordó otra cosa que puede resultarle útil. Steven F escribió ulplsql como una implementación PL/SQL de JUnit, la vanguardia Java del movimiento Test First. Sin embargo, las técnicas de TDD también se pueden aplicar a grandes cantidades de código heredado (en este contexto, el código heredado es cualquier conjunto de programas sin pruebas unitarias).

    La clave a tener en cuenta es que no tiene que poner todo bajo prueba unitaria inmediatamente. Comience de forma incremental. Cree pruebas unitarias para cosas nuevas, Pruebe primero . Cree pruebas unitarias para los bits que va a cambiar antes de aplicar el cambio, de modo que sepa que seguirán funcionando después de haber realizado el cambio.

    Hay mucho pensamiento en esta área, pero (inevitablemente aunque vergonzosamente) proviene principalmente de los programadores OO. Michael Feathers es el cap principal. Lea su artículo Trabajar de forma efectiva con código heredado . Si lo encuentra útil, posteriormente escribió un libro con el mismo nombre.