ITDD — Instrumentation TDD for Android using RESTMock
Some time ago I had an opportunity to work on a project that utilized a REST API in Android app (No big deal, right?). The API unfortunately had only a basic implementation and there wasn’t any test environment endpoint, so the only place I could work on was the production endpoint. If there is a red light turning on inside your head right now — good, the same thing happened to me. How am I supposed to work on production without the ability to modify the data so the other users won’t see that, and without breaking anything and being able to test different edge cases?
Go TDD with Unit testing!
At first I thought about utilizing the Unit tests in TDD(Test-driven development), but again, the app was purely displaying the REST API’s content, which held really minimal logic on the app’s side, much more important was the view displaying it correctly.
Then maybe dependency injection?
My second idea was dependency injection. As a big fan of it I thought it was a brilliant usecase for a DI, swapping the Network modules with the test ones. But again, imagine instantiating Model objects with some data the Java way:
Mock API Responses!
So finally I decided I will go with mocking API responses. At first I tried to use square’s mockwebserver but the way of specifying api responses there seemed too basic for me. So I decided to write my own library that is built on top of mockwebserver and let’s you specify API responses in much more clever way. And that is how the RESTMock library was born. It lets you match requests using Hamcrest matchers (the same you use in matching views in Espresso) and return JSON files saved in your test app’s assets folder. Specifying API Responses is as easy as:
RESTMockServer.whenGET(pathContains("users/defunkt"))
.thenReturnFile(200, "users/defunkt.json");
ITDD — the process explained
The first thing while starting developing an app is to setup the Android Instrumentation tests along with RESTMock (instructions here). Then I specify my first test:
I’m using a neat trick here knowing that sleeping in test won’t pause my tested application, I can have a certain screen running with a mocked out data. It’s a good approach when you want to manually check something before writing automation tests. After I am done with some basic Activity setup I start with writing the actual tests that will check the case I am actually working on:
Thanks to this I no longer have to launch the app, navigate to the proper screen and test it all manualy to check out whether my changes are working, additionally I have all my previous tests covering all the cases I’ve implemented before so I can be sure I won’t break anything during ongoing development. So you actualy save yourself time, have almost free UI tests which will make you look like a good developer carying about QA :) And finally, as Jon Reid said:
Android Sample
A good sample for Android app can be found here. It uses Dagger for Dependency Injection and Retrofit for communicating with Github API.
