Как понять, что делает хранимая процедура

Что проверяют

Умеете ли вы разобраться в чужой логике на стороне базы без помощи разработчика и превратить её в тест-кейсы. Следом обычно просят рассказать, как вы будете проверять процедуру, которая меняет данные сразу в нескольких таблицах.

Как отвечать

Идите от чтения кода к запуску:

• определение: достаньте текст процедуры. В PostgreSQL это \sf имя в psql или pg_get_functiondef, в SQL Server sp_helptext или OBJECT_DEFINITION, в Oracle представление ALL_SOURCE. В DBeaver и DataGrip то же открывается из дерева объектов;
• сигнатура: входные и выходные параметры, их типы и значения по умолчанию, что возвращается: набор строк, код результата или ничего;
• побочные эффекты: какие таблицы процедура читает, в какие пишет через INSERT, UPDATE, DELETE, вызывает ли другие процедуры, есть ли внутри COMMIT и обработка исключений;
• ветвления: каждая ветка IF и CASE даёт отдельный класс эквивалентности, а граничные значения параметров берутся прямо из этих условий;
• триггеры: на затронутых таблицах они срабатывают неявно и меняют итоговое состояние данных.

Потом запуск на тестовом стенде: внутри транзакции с последующим ROLLBACK или на копии данных. Если процедура сама делает COMMIT, откат не сработает, и нужна отдельная база. Снимите состояние таблиц до и после, сравните с ожиданием. При подозрении на медленную работу посмотрите EXPLAIN запросов внутри или профилировщик СУБД.

Документацию и комментарии читайте как гипотезу: верить стоит тому, что процедура делает на деле.

Где спотыкаются

Запускают процедуру на общем стенде без транзакции. Данные меняются, и соседние тесты начинают падать по непонятной причине.

Проверяют только возвращаемое значение. Процедура может вернуть «успех» и при этом не записать строку в журнал или записать её дважды, поэтому смотреть нужно на состояние таблиц.

Забывают про триггеры и вложенные вызовы. Кандидат описывает три UPDATE, которые видит глазами, а на деле процедура затрагивает ещё пять таблиц.