Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a way to access private plsql procedures for testing purposes?

I'm working on a project with a lot of plsql code and would like to add more specific unit-tests to our codebase. Some of the procedures/functions I like to test aren't in the package spec and I have no means to change that.

Is there a way to access these 'private' plsql procedures without adding them to the spec?

The only Idea I had so far, was to compile a special package spec to the DB before the tests, that specifies the procedures under test. I gues that would work, but I wonder if there is a simpler way, some evil secret oracle hack maybe ;-)

I'm testing from Java with JUnit/DBUnit.

BR Frank

like image 266
Frank Avatar asked Jul 20 '11 12:07

Frank


People also ask

How do I test a stored procedure in PL SQL Developer?

Select View > Unit Test. In the Unit Test navigator, right-click Tests and select Create Test. In Select Operation, select the hr_orcl connection that you used to create the AWARD_BONUS procedure. Expand Procedures, select AWARD_BONUS and click Next.

Is PL SQL used for testing?

The SQL Developer unit testing feature provides a framework for testing PL/SQL objects, such as functions and procedures, and monitoring the results of such objects over time. You create tests, and for each you provide information about what is to be tested and what result is expected.

How do you execute an anonymous block procedure?

Execute a PL/SQL anonymous block using SQL*Plus Second, turn on the server output using the SET SERVEROUTPUT ON command so that the DBMS_OUTPUT. PUT_LINE procedure will display text on the screen. Third, type the code of the block and enter a forward slash ( / ) to instruct SQL*Plus to execute the block.


2 Answers

There is a way to do this, providing you are on 10g or higher. It's called Conditional Compilation. This is a highly neat feature which provides special syntax so we can change our PL/SQL code at compilation time.

As it happens I have been using this feature precisely to expose private packages in a spec so I can run UTPLSQL tests against them.

Here is the special syntax:

create or replace package my_pkg
as

    $IF $$dev_env_test $THEN

    PROCEDURE private_proc;

    $END

    FUNCTION public_function return date;

end my_pkg;
/

That variable with the double-dollar sign is a Conditional Compilation flag.

If I describe the package we can only see the public package:

SQL> desc my_pkg
FUNCTION PUBLIC_FUNCTION RETURNS DATE

SQL>

Now I set the conditional flag and re-compile the package, and as if by magic ...

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>

Privatising the functions is as simple as you think it would be:

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>

We can do lots more with conditional compilation. It's covered in the docs. Find out more.

like image 70
APC Avatar answered Nov 16 '22 02:11

APC


I would be surprised if such a thing existed. The whole purpose of private procedures, functions and variables is that they are not visible to applications outside the package.

like image 43
Rob van Laarhoven Avatar answered Nov 16 '22 00:11

Rob van Laarhoven