Talk at Droidcon London 2017 Testing is a fundamental component for the success of our apps. Professionals in charge for developing Android apps are well aware of that and we are doing our best to add unit tests to our apps. But having a good test coverage is not an easy task. More so, when activities (or fragments) get in the middle. In this talk, I shared a brief introduction about how architecture helps us to increase code coverage and provided some practical hints. I did do some live coding to show how to use espresso and JUnit to write unit tests of an activity. The code was written in Kotlin, but the same can easily be done in Java. The video of this talk is here: (requires free subscription) https://skillsmatter.com/skillscasts/10534-cya-cover-your-app

1. CYA:
Cover Your App
Jorge D. Ortiz Fuentes
@jdortiz

2. A Canonical
Examples
Production

3. #AdvArchMobile
Agenda
★ Motivation
★ Facts
★ What’s missing?
★ Architecture
★ Live Coding
★ Recap

4. Motivation

5. But my code is
always awesome!

6. #AdvArchMobile
Selfish Unit Tests
★ No more discussions
★ No more explanations to the team
★ No more questions
★ No more bugs introduced by them
★ No more missed deadlines
★ No more late hours

7. #AdvArchMobile
Selfish Unit Tests
★ Prove (to others) instead of (your) intuition
★ No more explanations to the team
★ No more questions
★ No more bugs introduced by them
★ No more missed deadlines
★ No more late hours

8. #AdvArchMobile
Selfish Unit Tests
★ Prove (to others) instead of (your) intuition
★ Define contract and assumptions
★ No more questions
★ No more bugs introduced by them
★ No more missed deadlines
★ No more late hours

9. #AdvArchMobile
Selfish Unit Tests
★ Prove (to others) instead of (your) intuition
★ Define contract and assumptions
★ Document the code
★ No more bugs introduced by them
★ No more missed deadlines
★ No more late hours

10. #AdvArchMobile
Selfish Unit Tests
★ Prove (to others) instead of (your) intuition
★ Define contract and assumptions
★ Document the code
★ Easier refactoring or change
★ No more missed deadlines
★ No more late hours

11. #AdvArchMobile
Selfish Unit Tests
★ Prove (to others) instead of (your) intuition
★ Define contract and assumptions
★ Document the code
★ Easier refactoring or change
★ Better estimations for tests than debug
★ No more late hours

12. #AdvArchMobile
Selfish Unit Tests
★ Prove (to others) instead of (your) intuition
★ Define contract and assumptions
★ Document the code
★ Easier refactoring or change
★ Better estimations for tests than debug
★ Reusable code = code + tests

13. Prove correctness of
different aspects of
the public interface

14. Test the parts that
you aren’t
developing now

15. Facts

16. Coverage
=
Measurement

17. We want:
“Code is proven
correct in all cases”

18. We get:
“Lines used by the
tests”

19. Demo:
Demystifying
Coverage

20. #AdvArchMobile
What you have seen
★ Full CRUD
★ 100% Kotlin (everything but generated
code)
★ Mockito + Mockito-Kotlin
★ Good architecture
★ TDD

21. What is
Missing?

22. #AdvArchMobile
Not Covered
★ Dagger factories
★ Platform: implementation details (activities,
adapters, application subclass, DI)

23. Let’s do better

24. Architecture

25. MVP
ViewPresenterModel
display commands
events
fetch/change
data

26. Test View Methods
ViewPresenterModel
display commands
events
fetch/change
data

27. Test Events To Presenter
ViewPresenterModel
display commands
events
fetch/change
data
Presenter

28. #AdvArchMobile
How to Mock the
Presenter
★ App uses Dagger 2 for DI
★ Dagger 2 is NOT meant for Unit Testing
★ Activities use Service Locator for DI
★ Service Locator abstraction is implemented
by Application subclass
★ Unit tests use another Application subclass

29. And if I am an
MVVM Person?

30. Live Coding

31. Let’s write this
together

32. #AdvArchMobile
Recap
★ Unit Tests are good for you (and for others)
★ Code coverage is not the best metric
★ Good coverage is better
★ A good architecture will help to cover the
different aspects of your

33. Thank
You!

34. @jdortiz
#AdvArchMobile