Logo Icon Logo
A Crowd-sourced Cookbook on Writing Great Android® Apps
GitHub logo Twitter logo OReilly Book Cover Art
Doing Test-Driven Development (TDD) in AndroidBack to Android Cookbook Home | Up to Chapter: Testing

Author: Kailuo Wang ('kailuowang')
In Published Edition? Yes
FormatLanguage: WikiFormat

Doing Test-Driven Development (TDD) in Android


Lack of mocking support making TDD Android App cumbersome.


Setup 2 test projects: one created using the Android tool for the UI related tests, and another standard Unit Test projects for mock supported tests. Extract as much as your logic to the classes that can be unit tested.


In the official guide, the test related articles are mostly about testing the UI tests. An Android test project needs to be created so that it can be instrumented and deployed and test the app on a simulator environment. It's very cool and necessary for testing the UI related logic, but it also made mocking very difficult. There is some work around but they make things a bit ad hoc and potentially painful. If you step back and look at them from a higher level, these tests are more like integration tests than pure unit tests. They take longer to run, they require the whole environment up. Without mocking, they might need to test a lot more than a unit of functionality. All these justify the decision to make such tests a separate project/module from the normal unit test project/module. We can call this android tool created project/module the XYZ UI Test project, whose responsibility is to test only UI logic. Now you can setup another standard Unit test project as you always do. Let's call it the XYZ Unit Test project. Here you can use your favorite tools including mock frameworks. Also it's testing only all the non-UI related logic which avoids all the not-that-test-friendly Android UI API. Now all you need to do is to extract as much logic out of the nasty UI dependent classes and have fun TDD :)

See Also