👀 gRPC глазами тестировщика: почему 200 Ок ещё ничего не доказывает

В HTTP всё привычно:
дергаем GET /users/42, JSON в ответе, статус 404, значит такого пользователя нет - все просто 👨‍🦯

Открываете gRPC, а там

UserService/GetUser

И какой-то файл .proto

и ещё статусы вроде OK или NOT_FOUND. Первые пять минут хочется переехать на HTTP обратно 😅

gRPC позволяет клиенту вызвать метод другого сервиса почти как обычную функцию. Контракт обычно описан в том самом файле .proto: какие методы доступны, какие сообщения они принимают и возвращают. Данные чаще всего кодируются и передаются поверх HTTP/2.

⚠️ И вот главная ловушка:
Результат нужно смотреть по grpc-status:
- 0 означает OK, остальные значения обозначают ошибки.
- Вместо привычных 4xx и 5xx здесь встречаются INVALID_ARGUMENT, NOT_FOUND, DEADLINE_EXCEEDED и другие статусы.

Поэтому при проверке смотрим не только на транспорт:

• соответствует ли вызов контракту из .proto;
• верный ли gRPC-статус вернулся для конкретной ситуации;
• совпадают ли поля ответа и изменилось ли состояние системы как ожидалось;
• если метод потоковый, в каком порядке приходят сообщения и как закрывается поток.

Привычных URL и JSON может не быть. Но задача QA та же: понять, что вызвали, что получили и что реально изменилось в системе 💡

#Термин