Как выполнить модульное тестирование клиент-серверного кода

Question

В настоящее время я пишу клиент-серверное приложение Java. Поэтому я хочу реализовать две библиотеки, одну для клиента и одну для сервера. Связь между сервером и клиентом имеет очень строгий протокол, который я не хочу тестировать с помощью JUnit.

В качестве инструмента сборки я использую Maven и Husdon Server для продолжения интеграции.

На самом деле у меня нет хорошей идеи, как протестировать эти библиотеки клиент / сервер.

Я получил следующие подходы:

1. Просто напишите Dummy Client для тестирования сервера и напишите Dummy Server для тестирования клиента. Недостатки: К сожалению, это приведет ко многим дополнительным работам. Я не могу быть на 100% уверен, что клиент и сервер могут работать вместе, потому что я не уверен, что тесты полностью идентичны.

2. Напишите отдельный тестовый проект, который тестирует клиент и сервер вместе.
   Недостатки: Юнит-тесты не относятся к самому Проекту, поэтому Хадсон не будет запускать их автоматически. Каждый, кто что-то меняет в одной из этих библиотек, должен будет запустить тесты вручную, чтобы убедиться, что все правильно. Также я не буду получать отчет о покрытии кода.

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

Надеюсь, у кого-нибудь есть хорошее решение для этой проблемы.

Спасибо.

Answer 1

Думайте обо всем вашем коде как о «преобразовании ввода в вывод»: X -> [A] -> Y

X - это данные, которые входят, [A] - это трансформатор, Y - это выход. В вашем случае у вас есть эта настройка:

[Client] -> X -> [Server] -> Y -> [Client]

Итак, юнит-тесты работают так:

1. Вам необходим тест, который запускает код клиента для генерации X. Убедитесь, что код действительно выдает X с подтверждением. X должно быть final static String в коде.

2. Используйте константу X во втором тесте для вызова кода сервера, который преобразует его в Y (еще одна константа).

3. Третий тест проверяет, что клиентский код может анализировать ввод Y

Таким образом, вы можете сохранить независимость тестов и при этом убедиться, что важные части работают: интерфейс между компонентами.

Answer 2

Последний подход к решению этой проблемы - использование контейнеров Docker.Создайте файл Docker, содержащий базовый образ и все необходимые зависимости, необходимые для вашего клиент-серверного приложения.Создайте отдельный контейнер для каждого типа узла вашей распределенной клиент-серверной системы и протестируйте все взаимодействия API-интерфейса сервера точки входа с клиентом, используя TestNG или JUnit.Лучшая часть этого подхода заключается в том, что вы не издеваетесь над любыми сервисными звонками.В большинстве случаев вы можете организовать все сквозные взаимодействия клиент-сервер.

В этом подходе есть небольшая кривая обучения, но Docker становится очень популярным в сообществе разработчиков, особенно для решения этой проблемы.проблема.

Вот пример того, как вы можете использовать API клиента Docker для извлечения образов Docker в вашем тесте JUnit: https://github.com/influxdb/influxdb-java/blob/master/src/test/java/org/influxdb/InfluxDBTest.java

Answer 3

Итак, наконец, было решено построить многомодульный проект с отдельным модулем тестирования, включающим сервер и клиентский модуль Прекрасно работает в Хусдоне. И даже лучше в Eclipse IDE. Спасибо @ Аарон за подсказку

Answer 4

Мое предложение будет состоять в том, чтобы использовать два уровня тестирования:

1. Для вашего клиент-серверного проекта включите некоторые насмешки в свои модульные тесты, чтобы убедиться, что интерфейсы объектов работают должным образом.

2. После сборки проведите более обширный интеграционный тестовый запуск с автоматизацией для установки скомпилированного клиента и сервера в одну или несколько тестовых систем.Затем вы можете убедиться, что все детали протокола тщательно проверены.Этот интеграционный тестовый проект запускается при каждой успешной сборке проекта клиент / сервер.Вы можете использовать JUnit для этого и при этом получать обычный отчет от Гудзона.

Answer 5

Вы можете использовать любой фреймворк для создания фиктивных объектов.