![MVI Logging & Timetravel
• { "loading": true, "error": null, "contacts": null }
• { "loading": false, "error": null, "contacts": […] }
• { "loading": true, "error": null, "contacts": null }
• { "loading": false, "error": {NetworkError}, "contacts": null }](https://image.slidesharecdn.com/xingapptesting-170411082853/85/Android-centric-architecture-vs-unit-testable-apps-34-320.jpg)
Android-centric-architecture vs. unit testable apps
- 1. TESTING ANDROID APPS Android-centric architecture vs. unit-testable android apps
- 3. 150 8 +850 Offices EmployeesActive Clients What Where Netlight operates throughout Europe with offices in Stockholm, Oslo, Munich, Helsinki, Hamburg, Berlin, Paris and London. How Founded in Stockholm, Sweden, since 1999, Netlight has helped leaders in the digital industry to realise business critical projects in the forefront of technology. Netlight is an international consultancy firm that offers a full range of services with a focus on Technology and IT-Management.
- 5. QA SHOULD BE PART OF THE MINDSET OF A DEVELOPER, EVEN BEFORE HE STARTS WRITING CODE.
- 7. If you don't test your software your users will!
- 8. Agenda ‣ Why has testing been so hard? ‣ Android-centric architecture ‣ Model-View-Presenter (MVP) ‣ Model-View-ViewModel (MVVM) ‣ Model-View-Intent (MVI) ‣ Tools
- 9. Why has testing Android Apps been so hard? Testable code requires layers of abstraction, which have a performance cost Performance Concerns Misunderstanding Android Components Don’t architect your app around system components (Activities, Services, Broadcast Receivers, Content Providers) The rise of TDD Test-driven development was on the rise at the same time Android was
- 11. Android-centric architecture Activity Lifecycle Events Business Rules Access Hardware Access Sensors Framework APIs …. • Mix presentation logic with business rules • Code is difficult to understand • To rigid to handle varying use-cases • Tight coupling & low cohesion
- 12. Android-centric architecture Activity Lifecycle Events Business Rules Access Hardware Access Sensors Framework APIs …. • Mix presentation logic with business rules • Code is difficult to understand • To rigid to handle varying use-cases • Tight coupling & low cohesion Activity == View & Controller?
- 14. Model View Presenter (MVP) View Presenter Model
- 15. The presenter ‣ Make the presenter Framework independent ‣ The presenter does not depend on any android specific classes ‣ Abstract the presenter from implementation details ‣ Abstraction makes it possible to write non-instrumented tests
- 16. Model View Presenter (MVP) View <<Activity / Fragment>> Presenter <<POJO>> Model <<POJO>> IPresenter <<Interface>> IView <<Interface>> ViewPresenterContract <<Interface>>
- 17. Model View Presenter (MVP) View <<Activity / Fragment>> Presenter <<POJO>> Model <<POJO>> IPresenter <<Interface>> IView <<Interface>> ViewPresenterContract <<Interface>> Unit Tests Unit TestsInstrumented Tests
- 19. The presenter
- 20. The view
- 21. Unit test
- 22. Model View Presenter Clear separation of UI and business logic Separation Modularity Reuse of presenters and views Testing Testing in isolation without external dependencies
- 23. Model View ViewModel (MVVM) View ViewModel Model Observable / Databinding Reference
- 24. Model View Intent (MVI) View Intent Model State Actions
- 25. Model View Intent (MVI)
- 26. Facebook Flux Action Dispatcher Store Action View
- 27. MVI Principles ‣ Model that represents the state of the app ‣ Pure functions ‣ Unidirectional data flow ‣ Immutable data ‣ State reducer takes current state as input and produces the next state
- 28. MVI - Advantages ‣ Separates mutation and asynchronicity ‣ Makes testing much easier assertEquals(expectedModel, model) ‣ Readable code ‣ Predictable code
- 30. MVI Presenter
- 31. MVI View
- 32. MVI Unit test
- 34. MVI Logging & Timetravel • { "loading": true, "error": null, "contacts": null } • { "loading": false, "error": null, "contacts": […] } • { "loading": true, "error": null, "contacts": null } • { "loading": false, "error": {NetworkError}, "contacts": null }
- 35. Tools • JUnit • JaCoCo • Mockito • Espresso • Crashlytics • Infer • LeakCanary
- 36. KENT BECK