Очень полезно, что есть инструмент для генерации фиктивных версий клиентских заглушек. Тестирование на стороне сервера вызывает у меня тонны головной боли в данный момент. Достаточно головной боли, когда я чувствую, что должен делать что-то принципиально неправильное.
Возможно, я неверно истолковываю следующее, но в тестах end2end, включая mock_test, похоже, используется реальное соединение клиент-сервер для тестирования диска. Они могут издеваться над клиентом или издеваться над читателями / писателями клиента, чтобы увидеть ответ от сервера, но мне не ясно, как тестировать сервер изолированно.
Что я хочу иметь возможность do: у меня есть некоторые сервисные дополнения, которые наследуются от сгенерированного gRP C класса "Service". Предположим, что сервис предоставляет интерфейс ::grpc::Status Foo(::grpc::ServerContext* context, const CommandMessage* request, ::grpc::ServerWriter<CommandResponse>* writer); Мой инстинкт написания модульных тестов говорит, что я передаю фиктивный класс «ServerWriter» и ожидаю, что «Write» вызывается при необходимости. Но ServerWriter помечен как окончательный и не может быть переопределен.
Это не первое место, где я сталкиваюсь с проблемами, связанными с моими стандартными способами насмешек и серверными вещами gRP C. Класс Server, класс ServerBuilder и т. Д. c. Я завернул, чтобы я мог поставить их тестовые версии в тесты (чтобы убедиться, что правильные параметры передаются на мой сервер, когда он создается, например)
Так что я думаю, что что-то упустил с GRP c тогда. Я просто не знаю что. Должен ли я поддерживать настоящий сервер в своих модульных тестах и проверять его с помощью фиктивного клиента? Как проверить, что передаются правильные конфигурации сервера, если мне нужно подготовить тестовую версию с тестовыми конфигурациями? В коде есть классы интерфейса и виртуальные методы, но тогда части, которые кажутся открытыми для использования c, кажутся нелегкими, как я ожидал.