-
Notifications
You must be signed in to change notification settings - Fork 89
Conversation
|
||
|
||
@pytest.fixture() | ||
def grpc_userserceservicer(grpc_users_account): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Не могу понять что за словосочетание в названии функции. Так и задумано, там нет ошибки?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Здесь дествительно ошибка.
Я не нашел какого-то канона, мб он есть.
Поэтому собирался называть по следующему правилy: "grpc_{proto_file_name}_{objectname.lower()}"
Я для grpc клиента больше имел в виду интеграционные тесты написать. Здесь получается свой сервер и он же тестируется? |
Тут начинал тред .Сначала хотел тоже песочницу дергать. Наша цель: быть уверенными, что мы актуальный grpc клиент используем для своего верхнеуровнего api, если я правильно понимаю. Если прям мокать то это совсем плохо, наверно, потому что даже изменение прото клиента мы не заметим. Текущий подход вроде решает эту проблему: мы постоянно к сервису стороннему не обращаемся и в то же время мы всегда сервер сайд api тестируем ( при условии что proto сгенерированный клиент обновляем постоянно ). Но в целом можем заменить на реальный сервис -- это должно больше гарантий давать. А если эти тесты будут напрягать, сможем их соптизировать и после мерджа только прогонять например или по расписанию. Как делать? |
Я думаю, нужно на реальном сервере начать тестировать |
No description provided.