oracle unit-testing plsql junit

oracle - ¿Hay alguna manera de acceder a los procedimientos privados de plsql para propósitos de prueba?



unit-testing junit (4)

Estoy trabajando en un proyecto con un montón de código plsql y me gustaría agregar más pruebas unitarias específicas a nuestro código base. Algunos de los procedimientos / funciones que me gusta probar no están en la especificación del paquete y no tengo medios para cambiar eso.

¿Hay alguna forma de acceder a estos procedimientos de plsql ''privados'' sin agregarlos a la especificación?

La única idea que tenía hasta ahora era compilar una especificación de paquete especial para el DB antes de las pruebas, que especifica los procedimientos bajo prueba. Supongo que eso funcionaría, pero me pregunto si hay una forma más simple, algún hack secreto del oráculo tal vez ;-)

Estoy probando desde Java con JUnit / DBUnit.

BR Frank


Como dijo @Robert, no debería ser posible acceder a nada que esté declarado solo en el cuerpo del paquete fuera de ese paquete. Además, la creación de una especificación "especial" con el fin de ejecutar pruebas unitarias puede que tampoco funcione: si el cuerpo contiene declaraciones en adelante (declaraciones como las de la especificación, que generalmente se encuentran al principio del cuerpo), la especificación "especial" entrará en conflicto con esas declaraciones y el paquete no se compilará.


Hay una manera de hacer esto, siempre que esté en 10 g o más. Se llama compilación condicional. Esta es una característica muy clara que proporciona una sintaxis especial para que podamos cambiar nuestro código PL / SQL en el momento de la compilación.

A medida que sucede, he estado utilizando esta función precisamente para exponer paquetes privados en una especificación, por lo que puedo ejecutar pruebas UTPLSQL contra ellos.

Aquí está la sintaxis especial:

create or replace package my_pkg as $IF $$dev_env_test $THEN PROCEDURE private_proc; $END FUNCTION public_function return date; end my_pkg; /

Esa variable con el signo de doble dólar es una marca de Compilación Condicional.

Si describo el paquete solo podemos ver el paquete público:

SQL> desc my_pkg FUNCTION PUBLIC_FUNCTION RETURNS DATE SQL>

Ahora establezco la bandera condicional y vuelvo a compilar el paquete, y como por arte de magia ...

SQL> alter session set plsql_ccflags=''dev_env_test:true'' 2 / Session altered. SQL> alter package my_pkg compile 2 / Package altered. SQL> desc my_pkg PROCEDURE PRIVATE_PROC FUNCTION PUBLIC_FUNCTION RETURNS DATE SQL>

Privatizar las funciones es tan simple como crees que sería:

SQL> alter session set plsql_ccflags=''dev_env_test:false'' 2 / Session altered. SQL> alter package my_pkg compile 2 / Package altered. SQL> desc my_pkg FUNCTION PUBLIC_FUNCTION RETURNS DATE SQL>

Podemos hacer mucho más con la compilación condicional. Está cubierto en los documentos. Saber más.


Me sorprendería si tal cosa existiera. Todo el propósito de los procedimientos privados, funciones y variables es que no son visibles para las aplicaciones fuera del paquete.


Puede usar el desarrollador pl / sql para probar los procedimientos pl / sql.

1) Ir a los paquetes -> procedimientos / funciones
2) Haga clic derecho y seleccione "prueba"
3) Ingrese los parámetros de entrada y haga clic en el botón ejecutar / ejecutar y verifique los resultados.
4) puede ejecutar con una variedad de conjuntos de datos y verificar tablas de destino.
5) Ejecutar con datos no válidos y verificar los errores esperados.

puede obtener más detalles en http://www.handyinsight.com/2016/06/database-testing.html

Temruzinn