В настоящее время я пишу приложение Java Client Server. Поэтому я хочу реализовать два Библиотеки, один для Клиента и один для Сервера. Коммуникация клиентского сервера имеет очень строгий протокол, который я не тестировал с помощью JUnit.
Как инструмент сборки im, использующий Maven и сервер Husdon для продолжения интеграции.
На самом деле у меня нет хорошей идеи, как протестировать эти клиентские/серверные библиотеки.
Я получил следующие подходы:
Просто напишите Dummy Client для тестирования сервера и напишите Dummy Server для тестирования клиента. Недостатки: К сожалению, это приведет к многим дополнительным работам. Я не мог быть на 100% уверен, что клиент и сервер могут работать вместе, потому что я не уверен, что тесты полностью идентичны.
Напишите отдельный тестовый проект, который проверяет клиента и сервер вместе.
Недостатки: Тесты единиц не принадлежат самому проекту, поэтому Хадсон не будет запускать их автоматически. Все, кто что-либо меняет в одной из этих библиотек, должны будут вручную запускать тесты, чтобы убедиться, что все правильно. Также я не получу отчет о покрытии кода.
Есть ли какие-нибудь лучшие подходы к тестированию таких кодов? Возможно, проверьте проект Maven Multi Module или что-то в этом роде.
Я надеюсь, что у кого-то есть хорошее решение для этой проблемы.
Спасибо.
Итак, наконец, резолюция состояла в том, чтобы создать проект с несколькими модулями с отдельным тестовым модулем, который включает в себя сервер и клиентский модуль Прекрасно работает в Husdon. И еще лучше в Eclipse IDE. Спасибо @Аарон за подсказку
Подумайте о том, что весь ваш код "преобразует входной сигнал на вывод": X -> [A] -> Y
X - это данные, которые входят, [A] - это трансформатор, Y - это выход. В вашем случае у вас есть эта настройка:
[Client] -> X -> [Server] -> Y -> [Client]
Итак, модульные тесты работают следующим образом:
Вам нужен тест, который запускает код клиента для генерации X. Убедитесь, что код действительно создает X с помощью assert. X должен быть final static String в коде.
Используйте константу X во втором тесте, чтобы вызвать код сервера, который преобразует его в Y (другая константа).
Третий тест гарантирует, что код клиента может анализировать ввод Y
Таким образом, вы можете сохранить тесты независимыми и по-прежнему следить за тем, чтобы важные части работали: интерфейс между компонентами.
Мое предложение было бы использовать два уровня тестирования:
Для вашего проекта client/server включите некоторые издевательства в модульных тестах, чтобы гарантировать, что интерфейсы объектов работают должным образом.
После сборки выполните расширенный тестовый тест интеграции с автоматизацией для установки скомпилированного клиента и сервера на одну или несколько тестовых систем. Затем вы можете убедиться, что все детали протокола тщательно протестированы. Попробуйте запустить этот проект интеграционных тестов для каждой успешной сборки проекта клиент/сервер. Вы можете использовать JUnit для этого и получать обычный отчет от Hudson.
Вы можете использовать любую инфраструктуру макета для создания макетных объектов - Try jmockit.
Последний подход для решения этой проблемы - использование контейнеров Docker. Создайте файл докеров, содержащий базовое изображение и все необходимые зависимости, необходимые для вашего клиентского серверного приложения. Создайте отдельный контейнер для каждого типа node вашей распределенной клиент-серверной системы и протестируйте все взаимодействия API/клиента сервера точек входа с помощью TestNG или JUnit. Большая часть этого подхода заключается в том, что вы не издеваетесь над любыми вызовами службы. В большинстве случаев вы можете организовать все взаимодействия между клиентом и сервером.
В этом подходе есть немного кривой обучения, но Docker становится очень популярным в сообществе Dev, особенно для решения этой проблемы.
Вот пример того, как вы можете использовать docker client api для вывода изображений докеров в свой тест JUnit: https://github.com/influxdb/influxdb-java/blob/master/src/test/java/org/influxdb/InfluxDBTest.java