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
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.
As @Robert said, it shouldn't be possible to access anything that is declared only in the package body outside of that package. Furthermore, creating a "special" spec for the purpose of running unit tests may not work either: if the body contains forward declarations (statements like those in the spec, usually found at the beginning of the body), then the "special" spec will conflict with those declarations and the package won't compile.
You can use pl/sql developer for testing the pl/sql procedures.
1) Go to the packages--> procedures/functions
2) Right click and select "test"
3) Enter the input parameters and click execute/run button and verify the results.
4) you can run with varieties of data sets and check in target tables.
5) Run with invalid data and check for the expected errors.
you can get more details at http://www.handyinsight.com/2016/06/database-testing.html
temruzinn
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.