我正在处理一个包含大量 plsql 代码的项目，并希望在我们的代码库中添加更具体的单元测试。我喜欢测试的一些过程/功能不在包规范中，我无法更改。
有没有办法在不将它们添加到规范的情况下访问这些“私有”plsql 过程？
到目前为止，我唯一的想法是在测试之前为 DB 编译一个特殊的包规范，它指定了被测过程。我想这会奏效，但我想知道是否有更简单的方法，也许是一些邪恶的秘密预言机 ;-)
我正在使用 JUnit/DBUnit 从 Java 进行测试。
BR 弗兰克
【问题讨论】：
标签： oracle unit-testing plsql junit
您可以使用 pl/sql developer 来测试 pl/sql 过程。
1) 转到包--> 程序/函数
2) 右键单击并选择“测试”
3) 输入输入参数，点击执行/运行按钮，验证结果。
4)您可以运行各种数据集并检查目标表。
5) 使用无效数据运行并检查预期的错误。
您可以在 http://www.handyinsight.com/2016/06/database-testing.html
天妇罗
【讨论】：
有一种方法可以做到这一点，前提是您使用的是 10g 或更高版本。它被称为条件编译。这是一个非常简洁的功能，它提供了特殊的语法，因此我们可以在编译时更改我们的 PL/SQL 代码。
碰巧我一直在使用此功能来精确地在规范中公开私有包，以便我可以针对它们运行 UTPLSQL 测试。
这里是特殊语法：
create or replace package my_pkg
as
$IF $$dev_env_test $THEN
PROCEDURE private_proc;
$END
FUNCTION public_function return date;
end my_pkg;
/
带有双美元符号的变量是条件编译标志。
如果我描述包我们只能看到公共包：
SQL> desc my_pkg
FUNCTION PUBLIC_FUNCTION RETURNS DATE
SQL>
现在我设置条件标志并重新编译包，就像变魔术一样......
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>
将功能私有化就像您想象的那样简单：
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>
我们可以通过条件编译做更多事情。它包含在文档中。 Find out more.
【讨论】：
正如@Robert 所说，不应访问仅在该包之外的包体中声明的任何内容。此外，为运行单元测试创建一个“特殊”规范也可能不起作用：如果主体包含前向声明（类似于规范中的声明，通常位于主体的开头），那么“特殊”规范将与这些声明冲突，并且包将无法编译。
【讨论】：
如果存在这样的事情，我会感到惊讶。私有过程、函数和变量的全部目的是它们对包外的应用程序不可见。
【讨论】：