Для тестирования Java, я должен издеваться над клиентом или издеваться над сервером - PullRequest
0 голосов
/ 06 октября 2018

В архитектуре клиент-сервер, какой подход должен быть наилучшим, когда нужно издеваться над клиентом, а когда надо издеваться над сервером.Я понимаю, что модульные тесты должны проверять только данный класс, при этом каждый зависимый объект подвергается проверке, в то время как интеграционные тесты должны проверять функцию в целом.Когда дело доходит до вызовов API, я озадачен, должен ли я издеваться над клиентом, который я использую для вызовов API, или я должен использовать какую-то инфраструктуру для проверки подлинности сервера и позволить реальному клиенту вызывать поддельный сервер.

У меня возникла ситуациягде я должен (это не обязательно) проверить, попал ли я в правильный URL-адрес API, с правильным методом и с определенными значениями, переданными в параметрах запроса или в теле запроса.С помощью проверки клиента я могу просто «проверить», переданы ли заданные параметры (путь, метод, тело запроса), и считать тест успешным.Если мне нужно смоделировать сервер, то мне нужно немного обработать на ложном сервере, чтобы проверить, правильно ли переданы путь, метод и тело запроса, и вернуть значение.В этом случае ответ сервера - это единственное, что я могу использовать, чтобы измерить успешность теста (отправьте 500, если необходимые данные не получены).

По вашему опыту, как правильно тестировать вызовы вклиент-серверная архитектура для интеграционного тестирования?Если мы пойдем по книге, то следует использовать насмешку над сервером, но практично ли это в вышеупомянутом случае?Для модульного тестирования ясно, что следует использовать макеты.

Обновление: Чтобы избежать путаницы: я делаю клиента, который зависит от общедоступной службы, которой я не могу управлять.Итак, я проверяю, работает ли клиент должным образом, и сосредоточен ли он на клиенте.Вопрос связан с тем, должен ли я (в интеграционных тестах) макетировать клиентский объект, отвечающий за удаленные подключения (в моем случае WSClient из платформы Play), или мне следует использовать какой-нибудь серверный макет (например, веб-сервер okhttp mock).

Еще одно обновление: Большинство людей предлагают придерживаться простого эмпирического правила: если это модульные тесты, то имитируйте клиента, а если это интеграционные тесты, то используйте фиктивный сервер.Теперь мне любопытно узнать об этой ситуации: у меня есть класс A, который зависит от класса B, а у класса B есть клиентский объект, который выполняет удаленные вызовы.Если бы я должен был написать модульный тест для класса A, я должен издеваться над классом B, и это нормально.Однако, если я делаю интеграционное тестирование для класса A, допустимо ли макетировать клиентский объект в классе B и «проверять», переданы ли ему соответствующие параметры (путь, метод и тело запроса) или, для полноты,Я должен запустить фиктивный сервер, даже если проще манипулировать объектом клиента.В этом случае я не буду проверять таймауты и сетевые ошибки низкого уровня.Или весь смысл тестирования интеграции, в этом случае, должен состоять в том, чтобы также проверить сетевое соединение.

1 Ответ

0 голосов
/ 06 октября 2018

Вам необходимо:

  1. Интеграционные тесты - использовать сервер-заглушку, такой как Wiremock, тестировать реальные сценарии, такие как тайм-ауты, неправильный ответ, 500 и т. Д.
  2. Проверьте свой класс клиента - конечная точка фиктивного сервераиспользуя Mockito и проверьте ответ
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...