Absolutely everyone tests. The only difference is whether the test is automated or not.
Do you launch your app on a device to 'test' or do you write an espresso/unit test for it? You know you're doing one of them.
If you somehow don't do either, then your users are the de-facto testers ¯\(ツ)/¯
Unit tests are amazing, you can run through complicated scenarios really quickly with them, and fast feedback is essential to fast work that maintains your mental model of what you're working on.
However, unit tests can't cover everything. What if, in Android, you wanted to check if your handling of the back button works as you expected?
What if you wanted to see if clicking the thing actually opens the other thing? (yes have your UI state tested beforehand so you get early warnings if this isn't what you expect)
Even with that unit test, it's easy to not actually connect your ViewModel's observable to your navigation.
Hence we need Espresso.
But, since Espresso requires a lot of ceremony, resources and time to run, relegate it to only those parts of your system that your unit tests can't (reasonably) test.
Check out:
- Navigation
- Overall behaviour
Always keep it simple! When your designers go changing everything you don't want to have to change more tests than you need to.
It's better to trash a test that changes too often and learn what abstraction to write it with, than continuously go changing large swathes of tests each time something minor changes.
Good luck and reach out to me if you need help accelerating your entire Android team. I'm looking for a job.
Top comments (0)