Testing

Architecture components are one of the most exciting things that happened to Android in the past years. But how do you effectively go about and testing this?

Learning from analyzing code is one of the greatest ways to improve your skills. Can you spot the mistakes in the tests below? This post brings a fun little quiz for both testing gurus as novices, with a deep dive into the how and why of awesome tests.

While you may be tempted to strive for 100% code coverage, that would be a horrible idea. Besides some code being hard to test, the concept of coverage is actually fundamentally limited.

If you can code, you can also write unit tests. Writing awesome tests on the other hand is a different story. Don’t fool yourself: Unit testing code is production code that you will need to maintain, refactor and build upon for years to come.

The Mockito team is on fire lately! Not only did they add support to mock final classes and methods, but now they allow running Mockito directly onto an actual Android device.

Due to its clean simple api, Mockito has become world’s most popular Java mocking framework. After having covered all of its basics, it’s time to spice things up and start extending Mockito.

Code coverage is an awesome way to motivate you and your team to write more tests. But did you know that simply enabling it slows down your build significantly?

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.