I am very new to testing and TDD and I decided to use use Retrofit2-Mock for my api mocking needs. The documentation on Mock Retrofit2 is virtually non existent and the only how-to resources that I found is this article from 2015 and this answer from 2016.
In these a BehaviorDelegate class is used which does not implement the mocked api Interface and needs to be wrapped.
Is there a more elegant way to obtain the mock api service?
Or am I missing the whole point and the Retrofit2-Mock tool is not considered to be in the "best practice stack"? Specially since there are so few articles about it
The documentation on Mock Retrofit2 is virtually non existent and the only how-to resources that I found is this article from 2015 and this answer from 2016. In these a BehaviorDelegate class is used which does not implement the mocked api Interface and needs to be wrapped. Is there a more elegant way to obtain the mock api service?
In the previous post, I discussed implementing a custom Retrofit Client to mock out different HTTP response codes. This mechanism works well for Retrofit versions 1.9 and below but has its drawbacks. After trying out Retrofit 2, I have adjusted the previous sample and managed to achieve the same results (with some improvements ).
We're going to show how to mock Retrofit API calls in UI tests with a quick solution using MockWebServer and Hilt. 1. Replacing the Hilt Module with a Mock It's a good practice to have all you network dependencies together, it makes it easier for testing and debugging.
Retromock is a Java library for mocking responses in a Retrofit service that aims to cover as many potentially problematic cases in the future as possible. Retromock adapts a Java interface created by Retrofit using annotations on declared methods to define response mocks. Setting it up is very simple and can be done in the following steps:
This issue on Retrofit's Github repo is asking about the non-existent documentation you were asking about (it is still open while writing this answer).
Well, you have 2 options (both are in the article you already mentioned), and it depends on how you want to define your Givens/Inputs:
If you usually start your TDD by dealing with your backend's json response (using something like Postman), & you would feel more confident if you used that returned json directly as the input for your tests, then use MockWebServer
, where you would copy/paste the json you already have & start developing your tests from there.
If you prefer defining your givens/inputs using objects for the models you already use in your code, which would make your tests more readable & controllable, then use Retrofit's mock web server just like how it is used in this official sample mentioned by @JakeWharton
Both options are developed/maintained by the same awesome people of Square, so it is really about how you want to define your givens/inputs.
I usually use Mockito like this
Import Retrofit Mock
<dependency>
<groupId>com.squareup.retrofit2</groupId>
<artifactId>retrofit-mock</artifactId>
<version>${version.retrofit}</version>
<scope>test</scope>
</dependency>
Create and use the mock
import retrofit2.mock.Calls;
import static org.mockito.Mockito.when;
import static org.mockito.Mockito.mock;
...
Api api = mock(Api.class); // Mockito mock
...
when(api.doSomething(param)).thenReturn(Calls.response(response));
Retrofit Mock is used only to generate the response.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With