Приходилось ли работать с хранимыми процедурами?
Что проверяют
Дотягиваетесь ли вы до слоя, которого не видно через интерфейс. Если часть логики живёт в базе, проверка только через интерфейс оставляет половину веток непокрытой, и интервьюер хочет понять, осознаёте ли вы это.
Как отвечать
Объясните, что процедура это отдельный интерфейс со своим контрактом: имя, параметры, возвращаемое значение и побочные эффекты в таблицах. Значит её можно вызывать напрямую и проверять как функцию.
Что входит в проверку:
- результат и эффекты: мало сравнить возвращённое значение, надо смотреть все изменённые таблицы, включая журналы и счётчики;
- границы и NULL: пустая строка, ноль, отрицательное значение, несуществующий идентификатор, значения на краю диапазона. Через интерфейс такое часто просто не отправить;
- права: кому выдано право выполнения и не читает ли процедура больше, чем позволено вызывающему;
- конкурентность и повтор: что будет, если вызвать процедуру дважды подряд и одновременно из двух сессий;
- динамический SQL внутри: если запрос собирается строкой, проверяем экранирование кавычек и имён.
Из организации процесса: изоляция данных транзакцией с откатом вокруг теста или свежая база в контейнере, фикстуры в коде, а не руками на общем стенде. Для SQL есть свои фреймворки юнит-тестов, их упоминание всегда в плюс.
Где спотыкаются
Считают процедуру покрытой, потому что сценарий через интерфейс зелёный. Снаружи обычно достижима одна ветка из нескольких, остальные проверяются только прямым вызовом с нужными аргументами.
Тестируют на общем стенде без изоляции. Тесты начинают зависеть от порядка запуска, падают через раз и «чинятся» перезапуском, а настоящий дефект в этом шуме теряется.
Смотрят только на возвращённое значение. Процедура правит несколько таблиц, и лишняя строка в журнале или неверный остаток уезжают в прод, потому что проверка про них не знала.