The intent of this article to show how to cover by tests common Android use case. It is a simple common use case of getting data from web and showing it in the list when by pressing on the item app opens a new screen. Tech stack: Mockito, Robolectric, Espresso, MockWebserver, JavaRx
This project obtains web resource with help of JavaRx. Let’s share a few words about it.
JavaRx is an Android implementation of modern paradigm to write applications in functional style. It has two basic component -- Observer (the source of data) and Subscriber (the user of this data).
Observer is able to emit some data when Subscriber receive them and somewhere in the middle data might be processed in different ways.
Take a look at this example
This piece of code receives data from the server, cache and returns to subscriber. When client waits for data from the network it uses data from cache. Meanwhile, JavaRx allows to do many things with data on the fly, e.g. for this particular case data is transformed from one type to another.
Setup Mock WebServer
Our application gets data from the web server and for test purposes we have to emulate it to request and receive data. For this intent we MockWebserver.
Usage of MockWebserver is simple and straightforward. You setup it at the beginning of the test and shutdown at the end. To mock responses with url paths we have to instantiate Dispatcher. Let’s do it now.
This class receives request, extract path and depends on the call provide mocked response. Each url path might return several types of response, e.g. data and no data, with several types of error codes - SUCCESS or SERVER_UNAVALIABLE etc. To support this Dispatcher exposes several methods to modify type of response server returns based on the call. The details of mocked response are encapsulated into separate class WebResource.
The intent of automatic tests is verify correctness of code work under different scenarios. The value of such tests become high for project which requires maintenance and extension.
Here is a test which verify work of API
There is a retrofit class calls a request to the WebServer. Out mock WebServer return mock response wrapped as an Observable to allow process it by JavaRx operators.
TestSubscriber here is used to mock processing of data. It has several useful methods which helps us validate correctness of execution.
The next step is verification of user scenario. Here is MVP pattern helps a lot by separating model, view and business logic on several layers. The test of presenter looks like this.
Here is view class (Fragment or Activity that implements view interface) passed to presenter and mocked to isolate tests of methods calls from their implementation.
In some cases we have to emulate response of the method call where is necessary to properly process user scenario. Pattern doAnswer()-then()-methodCall() do this.
At the end of user scenario test verify does all necessary methods has been called.
The next step is implement user scenario for interface.
This tests covers scenario when user open the goals list, click on the item and see details screen. There are few interesting know-how.
First one is Robot pattern.
Standart espresso tests looks like a long screen of raw method calls. It is difficult to read and maintain. That’s why this logic is moved to methods which represent specific piece of logic and encapsulated in class with self-telling name Robot. Now it becomes much easier to read and maintain.
The second one is idling resource which helps system wait till the end of background operation. For goals screen we can not click on element till server return data and idling resource serves here to create a pause.
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly