Как использовать mockito для тестирования службы REST?
======================================================

Я очень новичок в модульном тестировании Java и слышал, что инфраструктура Mockito действительно хороша для целей тестирования.

Я разработал REST-сервер (методы CRUD) и теперь хочу его протестировать, но я не знаю как?

Еще больше я не знаю, как должна начаться эта процедура тестирования. Мой сервер должен работать на localhost, а затем делать вызовы по этому URL (например, localhost: 8888)?

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

Вот код для`initialize` метод.

В этом тестовом примере я хочу отправить строку Json на сервер (POST). Если все прошло хорошо, сервер должен ответить «Ваша схема была успешно создана!».

Может кто-нибудь, пожалуйста, помогите мне?

 проанализируйте входную строку как JSON и отправьте обратно`BAD_REQUEST` если он недействителен. Если это действительно так, создайте объект в`datastore` с различными свойствами (вы их знаете) и отправить обратно`OK`.

И вам необходимо убедиться, что этот контракт выполняется методом.

Где Mockito помогает здесь? Ну, если вы тестируете этот метод без Mockito, вам нужен настоящий`DataStoreService`, и вам нужно убедиться, что объект был создан правильно в этом реальном`DataStoreService`, Это где ваш тест больше не является модульным тестом, и это также, где он слишком сложен для тестирования, слишком длинный и слишком сложный для выполнения, потому что ему нужна сложная среда.

Мокито может помочь, высмеивая зависимость от`DataStoreService`: вы можете создать макет`DataStoreService`и убедитесь, что этот макет действительно вызывается с соответствующим аргументом объекта, когда вы вызываете`initialize()` метод в вашем тесте.

Чтобы сделать это, вы должны быть в состоянии ввести`DataStoreService` в ваш тестируемый объект. Это может быть так же просто, как рефакторинг вашего объекта следующим образом:

И теперь в вашем методе тестирования вы можете сделать:



portions кода; например, если вы потребляли свою службу REST, но не хотели выполнять полный тест стека, вы издеваетесь над службой, подключенной к службе REST, что позволяет вам точно и последовательно тестировать определенное поведение.

Чтобы протестировать внутренние части службы REST (например, конкретный метод службы), не обращаясь к базе данных, вы высмеиваете подсистему БД, позволяя тестировать только внутренние компоненты службы, не задействуя БД. Это тестирование принадлежит сервисному модулю REST, а не клиентской стороне.

Чтобы протестировать саму службу REST, вы используете реальную клиентскую библиотеку, создавая интеграционный тест с полным стеком. Здесь можно использовать Mockito, чтобы высмеивать части клиента, не связанные с потреблением услуг REST.



[интеграционное тестирование](https://en.wikipedia.org/wiki/Integration_testing) и Mockito (или любые другие фальшивые фреймворки) вам не очень пригодятся.

Если вы хотите написать код для юнит-теста, который вы написали, Mockito, безусловно, является полезным инструментом.

Я предлагаю вам прочитать больше о насмешках / юнит-тестировании и в каких обстоятельствах его следует использовать.



 что это не модульное тестирование, а интеграционное тестирование. В любом случае, вам лучше взглянуть на тесты джерси и встроенного сервера гризли. Подводя итог, этот код запускает сервер гризли (который также может запустить базу данных) по адресу localhost: 8888, затем настраивает клиента клиентского джерси и отправляет запрос POST, ответ на который должен быть проверен. Это интеграция, поскольку вы тестируете сервер и базу данных, однако вы можете использовать mockito для эмуляции базы данных, но это зависит от того, насколько связаны ваш сервер и база данных.

(тест с использованием джерси 1.11 и гризли 2.2)



om.github.tomakehurst wiremock 2.4.1 org.igniterealtime.smack smack-core 4.0.6

Определите и используйте wiremock, как показано ниже