Pruebas unitarias con utPLSQL

Las pruebas son un mal necesario del proceso de desarrollo de aplicaciones. Lamentablemente, las pruebas a menudo se pasan por alto o se pasan por alto cuando el tiempo es corto (seamos sinceros, ¿Quién no odia la fase de pruebas?). La distribución de código no probado o no marcado puede llevar a un código plagado de errores y a usuarios decepcionados. Las pruebas unitarias con un marco bien construido pueden ayudar a aliviar parte del tiempo que lleva ajustarse a un proceso de desarrollo bien probado.

Hay algunas opciones diferentes disponibles para probar tu código PL / SQL. La herramienta de Oracle SQL Developer:

• http://www.oracle.com/technetwork/es/developer-tools/sql-developer/overview/index.html

Proporciona algunas buenas opciones de depuración.

También puede usar instrucciones DBMS_OUTPUT dentro de su código para mostrar los resultados de las variables a medida que se ejecuta su código. Esta es una buena técnica para ayudar a identificar problemas en su código.

Frameworks de prueba para PL/SQL

Los más conocidos en la comunidad de Oracle son quizás Quest's Code Tester, especialmente con personas que trabajan con Toad y utPLSQL, que ha sido desarrollado por el superhombre de PL / SQL Steven Feuerstein, y las características integradas de Oracle SQL Developer.

• DbFit                                   
• Desarrollador Oracle SQL
• Pruebas unitarias PL / SQL para Oracle (PLUTO)
• PL / Unidad
• Quest Code Tester para Oracle
• ruby-plsql-spec
• utPLSQL

Por ejemplo el framework PLUTO (PL / SQL Unit Testing for Oracle) (http://code.google.com/p/pluto-test-framework/) es uno de esos marcos.

Otro es el marco de pruebas unitarias utPLSQL, creado por Steven Feuerstein  y este artículo se centrará en utPLSQL ya que es más ampliamente adoptado que los demás. El framework de pruebas unitarias  utPLSQL (http://utplsql.org/downloads/) puede aliviar parte del dolor de realizar las pruebas unitarias. El marco es fácil de usar y funciona muy bien para probar código bajo cualquier circunstancia que pueda imaginarse. Ahí también hay muchas opciones en utPLSQL que se pueden usar para mejorar el proceso de prueba de su unidad. Como resultado del uso de pruebas unitarias, sus aplicaciones serán más fiables, y pasará mucho menos tiempo manteniendo la base de código.

Prueba de código PL / SQL almacenado sin pruebas unitarias

Problema

Desea asegurarse de que un bloque de código PL / SQL funciona correctamente, pero no quiere tomarse el tiempo para escribe una prueba unitaria

Solución

Envuelves el código en las sentencias DBMS_OUTPUT que muestran o imprimen los resultados de intermedio y final, así como los resultados de pasos y ramas condicionales complejos. Esto te permitirá ver la ruta que toma el código cuando se llama a la función con los parámetros especificados. El siguiente ejemplo muestra esta táctica para colocar comentarios en ubicaciones estratégicas dentro de un código PL / SQL para ayudar a determinar si el código está funcionando como se esperaba. Por ejemplo, supongamos que desea pruebe rápidamente la función que presentamos en el ejemplo. Así es como lo modificarías para probar rápidamente la exactitud de sus resultados.

Cuando la función CALC_HORAS_TRIMESTRALES se ejecuta con un valor de 7.34, los comentarios se mostrarán como se ve en el siguiente fragmento de una sesión:

SQL> set serveroutput on

SQL> select calc_horas_trimestrales(7.34) from dual;

CALC_HORAS_TRIMESTRALES(7.34)

-----------------------

7.25

El valor pasado fue mayor a una hora ...

La porción decimal <= .375

El uso de instrucciones DBMS_OUTPUT dentro del código PL / SQL para mostrar datos o información perteneciente a la funcionalidad del código ha sido una gran táctica para probar el código en cualquier idioma. Como una cuestión de hecho,

es probablemente una de las técnicas más utilizadas para depurar código. La capacidad de ver valores como se calculan o para determinar cómo se maneja una condición puede ser muy útil para determinar si su código se está ejecutando como debería.

Para utilizar las sentencias DBMS_OUTPUT para probar tu código, debes colocarlas en estrategias ubicaciones. En el ejemplo de esta receta, los comentarios se han colocado dentro de cada uno de los bloques IF-ELSE para mostrar un poco de texto que le dirá al desarrollador cómo se procesan los valores dentro de la función.

Esto puede ser muy útil cuando se prueba el código porque una serie de números se puede pasar al función para determinar si se está devolviendo el resultado correcto. Si no, entonces podrás  para ver exactamente dónde se está evaluando incorrectamente el código.

Aunque el uso de instrucciones DBMS_OUTPUT en el código puede ser muy útil para determinar dónde se encuentra el código funcionando correctamente, puede causar desorden y también puede crear sus propios problemas. Por ejemplo, si te olvidas de colocar una cita después de una de las instrucciones DBMS_OUTPUT que coloca en su código, entonces el código no se compila correctamente, lo que hace que busques la causa de otro problema. Además, es una buena idea eliminar las instrucciones de salida antes de que el código se libere en producción. Esto puede tomar un tiempo, que podría ser mejor invertido en el desarrollo. Como un medio para probar pequeñas unidades de código, usando DBMS_OUTPUT funciona bastante bien. Sin embargo, si desea desarrollar suites de prueba completas y una unidad automatizada probando, entonces debes de continuar leyendo el resto del artículo.

Instalar utPLSQL

Problema

Has elegido el marco de pruebas de unidad utPLSQL para PL / SQL para tu trabajo y quieres instalarlo.

Solución

Primero, descarga las fuentes de utPLSQL. Una vez que hayas obtenido las fuentes, sigue los siguientes pasos para instalar el paquete utPLSQL en la base de datos para la cual desea escribir las pruebas unitarias y ponerlo a disposición para todos los esquemas.

Crea un usuario para alojar las tablas, paquetes y otros objetos de utPLSQL. Por ejemplo, el usuario se llamará UTP y se usarán los tablespaces permanentes y temporales predeterminados.

Otorga privilegios al usuario UTP recién creado utilizando GRANT <privilege_name> TO  <user_name>, reemplazando valores con el privilegio apropiado y nombre de usuario El usuario requerirá los siguientes privilegios:

• Create session
• Create procedure
• Create table
• Create view
• Create sequence
• Create public synonym
• Drop public synonym

Instalaa los objetos ejecutando el script ut_i_do.sql.

SQL> @ut_i_do instalar

Una vez que se hayan completado estos pasos, tendrás la posibilidad de ejecutar pruebas unitarias en paquetes que se cargan en diferentes esquemas dentro de la base de datos.

Usar utPLSQL

Problema

Te gustaría construir un paquete de prueba de unidad para uno o más de los objetos PL / SQL en su esquema de base de datos.

Solución

Deseas construir un paquete de prueba utPLSQL para probar un objeto en su base de datos. Un paquete de prueba consta de dos archivos separados, un encabezado de paquete y un cuerpo de paquete.

Cree un encabezado para el paquete de prueba y guárdelo en un archivo con el mismo nombre que le ha asignado al encabezado y con un sufijo .pks.

Un archivo de encabezado contiene tres procedimientos: 

• ut_setup, 
• ut_teardown 
• El procedimiento que realiza las pruebas unitarias del objeto de destino en su base de datos. 

Por ejemplo, supòn que deseas crear un paquete de prueba de unidad para probar el código de la función CALC_HORAS_TRIMESTRALES. Este encabezado de paquete debe almacenarse en un archivo llamado ut_calc_horas_trimestrales.pks y cargado en la base de datos cuyos objetos estás probando.

Cree el cuerpo del paquete que implemente los procedimientos especificados por el encabezado del paquete de prueba de la unidad y guárdelo como un archivo con el mismo nombre que el encabezado, pero esta vez con un sufijo .pkb. El siguiente cuerpo del paquete debe almacenarse en un archivo llamado ut_calc_horas_trimestre.pkb y cargarse en la base de datos.

El cuerpo del paquete en este ejemplo se ajusta al formato que se debe usar para probar paquetes usando el marco utPLSQL.