Есть ли способ доступа к частным процедурам plsql для целей тестирования?

Я работаю над проектом с большим количеством кода plsql и хотел бы добавить более конкретные модульные тесты в нашу кодовую базу. Некоторые из процедур/функций, которые я испытываю, не входят в спецификацию пакета, и у меня нет никаких средств для его изменения.

Есть ли способ получить доступ к этим 'private' процедурам plsql без добавления их в спецификацию?

Единственная идея, которую я до сих пор делал, заключалась в том, чтобы скомпилировать спецификацию специального пакета для БД перед тестами, которая определяет процедуры, которые проверяются. Я думаю, что это сработает, но мне интересно, есть ли более простой способ, какой-то злой секретный оракул, может быть, -)

Я тестирую Java с помощью JUnit/DBUnit.

BR Франк

Ответы

Ответ 1

Есть способ сделать это, если вы на 10 г или выше. Это называется условной компиляцией. Это очень аккуратная функция, которая обеспечивает специальный синтаксис, поэтому мы можем изменить наш код 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>

Мы можем сделать намного больше с условной компиляцией. Это описано в документах. Подробнее...

Ответ 2

Я был бы удивлен, если бы такая вещь существовала. Вся цель частных процедур, функций и переменных заключается в том, что они не видны приложениям вне пакета.

Ответ 3

Как сказал @Robert, не должно быть доступа к чему-либо, что было объявлено только в корпусе пакета за пределами этого пакета. Кроме того, создание "специальной" спецификации для запуска модульных тестов может также не работать: если тело содержит форвардные объявления (такие как те, что указаны в спецификации, обычно встречающиеся в начале тела), тогда "специальная" спецификация будет противоречить этим объявлениям, и пакет не будет компилироваться.

Ответ 4

Вы можете использовать разработчик pl/sql для тестирования процедур pl/sql.

1) Перейти к пакетам → процедуры/функции
2) Щелкните правой кнопкой мыши и выберите "тест"
3) Введите входные параметры и нажмите кнопку запуска/запуска и проверьте результаты.
4), вы можете запускать многообразие наборов данных и проверять целевые таблицы.
5) Запуск с недопустимыми данными и проверка ожидаемых ошибок.

вы можете получить более подробную информацию по адресу http://www.handyinsight.com/2016/06/database-testing.html

temruzinn