Использовали ли удаленный вызов процедур (RPC)

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

Понимаете ли вы RPC как подход, а не одно слово, и умеете ли тестировать API, не похожие на REST. Следом спрашивают, чем тест gRPC отличается от REST и чем вы вызывали методы.

Как отвечать

RPC это не конкретный протокол, а модель: клиент вызывает удалённую функцию так, будто она локальная, по имени метода и с параметрами. Частые реализации:

• gRPC: HTTP/2 и Protocol Buffers, контракт в .proto, клиентский код генерирует protoc. Бывают унарные вызовы и три вида стриминга;
• JSON-RPC 2.0: один эндпоинт, в теле method, params и id, ошибка приходит объектом error с кодом, например -32601 для несуществующего метода;
• SOAP, Thrift, XML-RPC: встречаются в старых интеграциях.

Если опыт был, расскажите на своём примере: какой сервис, чем вызывали, что проверяли. Для ручной работы есть Postman, Insomnia и консольный grpcurl, ему удобно, когда на сервере включён reflection. Автотесты пишут на сгенерированных стабах, например pytest с grpcio или JUnit с grpc-java, нагрузку дают через ghz.

Что проверять в gRPC сверх обычного:

• статусы: не HTTP-коды, а INVALID_ARGUMENT, NOT_FOUND, UNAUTHENTICATED, DEADLINE_EXCEEDED, UNAVAILABLE;
• дедлайны: сервер соблюдает таймаут клиента и корректно прерывает работу;
• метаданные: токены и заголовки трассировки;
• совместимость контракта: старый клиент с новым .proto, удалённые и переименованные поля.

Если с RPC не работали, скажите честно и покажите, как перенесёте опыт тестирования REST: контракт, негативные сценарии, авторизация. Начали бы с чтения .proto и ручных вызовов через grpcurl.

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

Смотрят только на HTTP-статус. В gRPC и успешный, и ошибочный ответ обычно приходят с HTTP 200, результат лежит в grpc-status. В JSON-RPC ошибка тоже часто приходит с 200 внутри тела.

Не знают про значения по умолчанию в proto3. Неприсланное число становится 0, строка пустой, и без optional или обёрток не отличить «не передали» от «передали ноль».

Не тестируют стриминг и отмену: обрыв потока клиентом на середине, порядок сообщений, медленного потребителя. Утечки соединений потом всплывают под нагрузкой.