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.
