Приятно слышать ;-) Можете написать в личку в телеграмме @denis_dbd , если нужны консультации.

Саша, я даже не сразу сообразил, что это ты :) Магниту привет, если ты еще там :)

@@OracleDBD да ещё тут. Передам. Удачи в развитии канала. Контент у тебя стоющий! Продолжай в том же духе!

Хорошее начинание, если что задавайте вопросы в телегу.

@@OracleDBD Видео отличное, спасибо! В телегу не совсем понимаю куда писать. В личку лезть как-то неудобно. Наверное в канале было обсуждение по ролику, но полгода назад, искать как-то лень. Напишу вопрос сюда. utPLSQL пока кажется вполне юзабельным. Установил тут уже немного и попробовал. Как в тестах работу с таблицами БД вести - понятно. В %before добавил данных для теста, отработал тест, в %after снёс. А что делать если в коде используется скажем рассылка писем через utl_smtp.open_connection() и прочее utl_smtp.mail() и т.д.? Как это мокировать? В документации ничего про такое не нашёл, хотя прочёл вроде бы всю. Я так понимаю можно вообще не тестировать эту логику. Но ведь хочется скажем само формирование писем протестировать, проверить что тело письма при таких-то данных в таких-то таблицах должно быть равно тому-то. Вижу вариант: отключать на время тестов вызовы utl_smtp. Например через условную компиляцию (устанавливать для тестов "set alter session plsql_ccflag" во что-то и в зависимости от него вообще не компилить вызовы utl_smtp, оставить только логику создания тел писем). По-моему вариант. Но может быть есть другие варианты? Коллеги, подскажите.

@@JashKa Привет! Я не звездная персона, вполне переживу сообщение в личку в телеге - @denis_dbd =) Что касаемо вопроса. Да замокировать как в middleware (Java/Kotlin) не получится. К сожалению. Что можно сделать? Зависит от реализации, возможности/наличия времени править код и необходимости тестировать именно этот кусок с внешними зависимостями. Например: 1. Сделать обертку над utl_smtp. Смотреть на переменную контекста (sys_context). Для тестов её ставить в "1". по умолчанию "0". Для "1" utl_smtp не дергать. 2. Разбить тестируемые функционал на более мелкие модули. Аля если была бооольшая функция отправки, в которой формировалось сообщение, подгребались адресаты, ..., затем отправка. Разбить её на логические куски и тестить их отдельно. Наверняка, есть и другие варианты решения.

@@OracleDBD Через sys_context тоже вариант, но тогда получится что в боевом коде будут как бы куски тестировочного кода. Не совсем правильно по-моему. А в общем да, направление мысли примерно одинаковое у нас. Ну как ещё? Чудес не бывает. Хотя... А вдруго кто из коллег чего-нибудь более хитрое подскажет? Подождём.

@@JashKa условная комп/контекст или другие способы. Может быть, кто-то подскажет более элегантные варианты - "одну и ту же задачу, можно решить разными способами"

Все, конечно же, зависит от конкретной ситуации. Unit-тестирование хорошо подходит для отдельных конечных функциональностей. Если возвращаться к вопрос. У нас есть функция "A", в которой выполняется сложный запрос, который собирает какие-то данные и выплевывает ответ. Если возможно, нужно создать такие данные, на которых бы она вернула предсказуемый ответ и сравнить ожидаемое и фактическое значения. Это не всегда представляется возможным.

Все силы и время брошены на курс по PL/SQL для новичков.