Unit testing Android app using Robolectric and Android Studio 1.0.1
12/16/2014, 12:16:00 PM
I have been reluctant to write tests for my Android projects because…
- I didn’t really know what to test. TextView.is.visible.and.hasText(“Hello World”). Er, um.
- I did write some tests as experiments. It runs and start activities in my device. If I didn’t connect my device to my mac, it runs in the emulator. It is slow and it does destruct my focus on writing code.
At one of the greatest meetup experience of any kind that was held at Spotify NYC office by NY Android developers meetup group, I learned less painful ways of doing unit tests for Android dev. Robolectric. It allows an Android project to run inside JUnit/IDE. Woot! I have got to try that.
I thought that Robolectric was mostly a drop-in replacement of a standard Android testing framework that is installed when you create a new project in Android Studio. I was wrong. It took 8 hours worth of my spare time to get it finally working with `gradlew test` inside the Terminal window of Android Studio 1.0.1. It took another 4 hours to figure out running on JUnit test runner inside Android Studio 1.0.1 IDE.
Instead of writing in a human readable language on how I made it work, I compiled my journey into a stream of commits in my GitHub repository. It should address many if not most of the issues you would be facing if you start doing the same stuff by yourself. I saw a lot of StackOverflow questions about it. Some of them are still applicable to Android Studio 1.0, but many of them were stale (don’t get me wrong. They were really helpful for me to figuring out where to look at. I appreciate it. That is why I list most of them in this writing later).
So, try it by yourself (may be with some help from my GitHub repository) and enjoy writing unit tests with Robolectric inside Android Studio 1.0.1!
Here is the list of most helpful links that I found during my journey of making it all work.
-
This is the default “installation” suggested by Robolectric. It works. The contents of build.gradle are what I copied to the first half of my “MyApplication” project. But simply importing all gradle settings fails MyApplication because Robolectric currently supports API level 18 and the project Android Studio 1.0.1 creates targets 21.
-
This SO is where I found a solution to API level issue. This one also reminded me that there are more than a few configuration you can specify in @Config annotation.
-
After I added AssertJ Android (that I also learned at the meetup), I started to see a build error again. This “temporary” solution is still required as of this writing to solve the issue.
-
ResourceNotFoundException wasn’t there for the first time I started this “project”, but it was because I changed MainActivity extends from Activity. The default was ActionBarActivity that Android Studio 1.0.1 generates, which raises the ResourceNotFoundException. This thread helped me find “qualifiers” attribute. But the suggested value “v10” didn’t work because I was using suport library 21.0.3 which has “v11”.
-
http://blog.blundell-apps.com/android-gradle-app-with-robolectric-junit-tests/ and http://blog.blundell-apps.com/how-to-run-robolectric-junit-tests-in-android-studio/After I was satisified with running tests by `gradlew test`, I added JUnit configuration to the project so the tests can run inside IDE with some nice visual and debuggability. It failed in many ways. These tutorials by Blundell helped me a lot to figure out how to run it in the IDE. The document was not for Android Studio 1.0.1 and some information may be stale and not applicable by now (for example, I didn’t have to specify Alt JRE, and I didn’t have to create a “testClasses” gradle configuration), but I wasn’t able to figure out to do it by creating a Java library outside of the app project and refer to the app project from it, without these tutorials.
-
I wasn’t able to “reproduce” this particular error when I was compiling my findings one step at a time, but I am sure I was hit by the error. This thread was where I found project.properties can specify libraries to look at. But later I found that you can also put library path to @Config attribute, which was handier for this project.
Thanks to all of you who keeps records of what works and what doesn’t work. Hope this entry and my GitHub repository also serve somebody in the future.
Last but not the least, Thanks Sean Kenny who did the presentation at the meetup. I also had to say thanks to Erik Hellman who also did another great presentation at the meetup. OMG, Spotify sounds like a great place to work. Thanks New York Android Developers Meetup. I learned a lot from them.