The document discusses the importance of 'selfish unit tests' which promote code correctness and reduce bugs, missed deadlines, and late hours. It emphasizes defining contracts, documentation, and proper architecture for effective testing, while also addressing the limitations of code coverage metrics. Additionally, it outlines the use of Dagger 2 for dependency injection in unit testing and encourages collaborative coding for better practices.

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