Member-only story
Seven Principles of Great Unit Tests — Adapted For Android
When it comes to software engineering it’s usually easy to find sources about how to write good code that is ready for production. You can look into Clean Architecture or SOLID Principles (or both) and have a good idea of how to reliably write good code. However when it comes to writing good unit tests I’ve found we tend to throw good engineering practices out the window. What’s even worse is testing on Android still isn’t commonplace, this has resulted in lackluster information about how to test on the platform. So with all of that out of the way, what are the seven principles of great unit tests?
1. Fast
One of the major benefits of writing unit tests is it allows you to document how your code should work (as well as prove it actually works). The only way you can take advantage of that benefit is if your tests are fast. Engineers are impatient (as most people are), if it takes more than a second to verify your code works there is little chance you will want to run them with any sort of frequency. Running tests frequently is crucial to finding regressions in your code, the longer you wait, the more time you’ll spend figuring out why a test is failing.
Making sure your unit tests are fast isn’t something I cared about until I had to wait 15 minutes for 2,000 unit tests to execute. While writing tests for Android I’ve discovered a few things to avoid if you want to have fast tests. The first thing you should do is say no to Robolectric. While Robolectric has it’s benefits, the last time I used it in a project I spent 30 seconds waiting for it to initialize in most tests. If you want to use Robolectric you should ensure it runs separately from your actual unit test suite.
The second thing you should do is limit your reliance on things like PowerMock since preparing a static function can take upwards of one second. In most cases you can avoid using PowerMock by writing code that doesn’t rely heavily on statics.
The third is only use Mockito when you actually need to, using it to mock a data class is probably overkill. However if you have some complex business logic you need to mock (such as a UseCase) then it’s probably worth using a mocking framework.
