Testing made sweet with a Mockito

At Droidcon Berlin 2016 I had a great time talking about testing using the Mockito framework. While the talk wasn’t recorded unfortunately, the great folks at Voice Republic recorded an audio version which you can listen to as a podcast or together with the slides.

Talk

The past year has been huge for Android testing: Testing support lib, fast JVM unit tests,… Having such great tools means writing tests is a breeze! All your apps currently have >80% code coverage, right? Yay! Or wait… is it really? Is all your common Android logic (networking, databases,…) tested? Do you isolate parts of your code base to keep your tests small? And what about providing relevant testing data?

In order to achieve this, you need to make use of mocks and stubs. And that’s exactly what this talk will be about: What is a mock? What’s the difference between a mock and a stub? Are mocks the only way to provide relevant data for your unit tests? What do I do with all the final classes/methods in the Android SDK? How do I architect my app to make it easier to test? …

After having adopted TDD as my main development workflow for almost a year now, I feel comfortable saying everything can be tested. Its just a matter of having someone experience show you how.

Code

A fully working sample project with all principles is available on Github.

• build.gradle file indicating how to configure Mockito
  • testCompile: for tests run on your computer in a JVM (src/test folder)
  • androidTestCompile: for tests run on an Android device (src/androidTest folder)
• UserTest class demonstrating Mockito usage
  • TLDR: JVM unit tests with mockito are easy to read and write
• UserTestAndroid class demonstrating Mockito usage on Android device
  • TLDR: Mockito can be used on Android, but need to use V1 and dexmaker
• HandlerWrapper class indicating how to test final methods
  • TLDR: Wrap final or statics methods with a different non static/final method
• TestUserData class indicating how to provide testing data for POJO objects
  • TLDR: Override all methods with default values instead of creating a mock and stubbing them out

Audience