Practical network for Android Developers (part 5)

Easy data layer for every Application

Here is the list of the blogs in this series:

• Part 1 — HTTP and Network Layer
• Part 2 — TLS, Certificates, and Pinning
• Part 3 — Authenticators and Interceptors
• Part 4 — Performance, Redundancy, and Concurrency
• Part 5 — Testing and Integration

Practical network for Android Developers

This is the final part of this series “Practical Network for Android Developers” today we are gonna discuss testing and the way we can handle specific integrations of details with an HttpClient and other things to address like mocking and testing

I will create a second part outside this serial just to address any integration details of coroutines to a network request (even testing), whatsoever, feel free to ask any question below.

Testing

Testing is probably one of the most important parts for Android developers, it helps to understand the logic behind the code we are writing and usually help us to handle troubleshooting in the easiest way, in a more product like vision, it give you capabilities to handle fidelity, execution times, debugging and maintenance.

On Android, testing is composed of three main stages:Unit Testing, Integration testing and UI testing

• Unit Testing This is probably the most basic testing strategy. By creating and running unit tests against your code, you can easily verify that the logic of certain parts is correct, unit tests are local these tests are compiled to run locally on the JVM to make it easier for developers and pipelines.
• Integration TestingIntegration tests verify how different units collaborate with one another. Validate either interaction between levels of the stack within a module or interactions between related modules, this can help us to verify a little deeper some integration with the unit testing.
• UI Testing Usually, we need to test flows that are followed by our users to perform some actions, this test is UI testing. You can write your own test and putting an emulator to run this process so you can verify the process is correct, or you can even use Firebase Test Lab to run this test in another process, for this part of the serial we are not gonna talk about this

We may need some libraries to implement testing, principally for Unit testing and Integration testing, for example JUnit that is in charge of provide simply API to write testing operation, we may need some flavor of Mock (Mockito, Easymock, or any other fancy flavor that is brand new) and we need to talk about MockWebServer that is part of OkHttp, where you can easily mock server responses completely, the implementation is actually as simple as OkHTTP:

testImplementation("com.squareup.okhttp3:mockwebserver:4.9.0")

Inside the OkHttp documentation for MockWebServer, we can found this description:

A scriptable web server. Callers supply canned responses and the server replays them upon request in sequence.

We may have two important parts of this testing, the first one is MockWebServer class and the second one is MockResponse

The reason is that MockWebServer is the class that will act as an Interceptor (if you haven’t check interceptors I do recommend to check Part 3 — Authenticators and Interceptors of this serial) and will modify the HTTP request and response depending on the configuration of the MockResponse that is an OkHttpClient Response that can be fully configurable, we can modify Http response code, Frames of the body and Frames of the headers.

We also need to review takeRequest() functionality, which pretty much awaits the next HTTP request, removes it, and returns it. Callers should use this to verify the request was sent as intended. This method will block until the request is available.

So if the MockWebServer acts as an Interceptor, then we can even test our Authenticators and our Interceptors, and this is a huge advantage to use OkHttp, cause if we can test every layer of this in an Unit Testing and Integration mode then, we are offering a full layer tested, and once we made the UI, we will end up with a full suite for our application, so let's create a MockWebServer:

Feel free to add a lateinit or a simple nullable variable, I prefer this method in the post of immutability, the MockWebServer only need to be started at the Before method and shutdown in the After.
Let’s add a simple MockResponse with the frames of Body and a Header:

MockResponse has the same setters and getter that a normal Response, can even be used to check connection, request, and response times, also we can add a ResponseCode option too. Now, let see some asserts to verify the response is correct.

We need to Enqueue our MockResponses, as Interceptors, they depend on the way we are putting them on the list, the first Request will get a Response with the first enqueued Response, and so on overall the Request, we may have. We can also add a TimeOut to the TakeRequest option to verify the request was sent as intended between the given time.

There’s even a way to make MockServer available for Instrumental Testing so you can init view with the responses that need to be populated and handle in a simpler way.

This is all for this serial. Feel free to ask any question here or at my Twitter account that you can found below!
I’m so excited, honored, and happy to announce that I’ve become a Google Developer Expert on Android!

We grow as a community together! Incredible things are around the corner, thank you so much for reading this serial, wait for the next one!

If you need help, I’m always happy to help, you can find me here:
Medium as Dinorah Tovar
Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar

Happy Coding! 👩🏻‍💻