Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Android MV* Patterns & Unit Testing

Paresh Mayani
November 26, 2016

Android MV* Patterns & Unit Testing

"Android MV* Patterns & Unit Testing", talk delivered in DevFest Ahmedabad 2016 http://devfest.gdgahmedabad.com/

- Android MVC vs MVP vs MVVM
- Android Unit Testing
- Why Unit Testing
- Why Good code base
- Android Testing frameworks and tools
- Continuous Integration in Android

Paresh Mayani

November 26, 2016
Tweet

More Decks by Paresh Mayani

Other Decks in Technology

Transcript

  1. MV (C | P | VM) Model Business logic Data

    source of the application Network layer, database operations
  2. MV (C | P | VM) View Business logic Data

    source of the application Network layer, database operations Responsible for displaying data Model
  3. Presenter Model View 1 .. 1 Presenter is a simple

    java class that do not contain any UI components, it just manipulates data from model and display in on View.
  4. Passes call to Fire events Manipulates Model-View-Controller Controller Model View

    User Interaction Passes call to Manipulates Model-View-Presenter Presenter Model View Updates User Interaction Fire events
  5. Passes call to Fire events Manipulates Model-View-Controller Controller Model View

    User Interaction Passes call to Manipulates Model-View-Presenter Presenter Model View Bi-directional Data Binding Manipulates Model-View-ViewModel ViewModel Model View Updates User Interaction User Interaction Fire events Fire events
  6. Located at module-name/src/test/java/. These tests run on the local JVM

    and do not have access to functional Android framework APIs. Local unit tests
  7. Located at module-name/src/androidTest/java/. These are all tests that must run

    on an Android hardware device or an Android emulator. Instrumented (end-to-end) tests
  8. “Unit Testing is a level of software testing where individual

    units/ components of a software are tested. “ The purpose is to validate that each unit of the software performs as designed.” All possible scenarios
  9. // You can mock concrete classes and interfaces TrainSeats seats

    = mock(TrainSeats.class); // stubbing appears before the actual execution when(seats.book(Seat.near(WINDOW).in(FIRST_CLASS))).thenReturn(BOOKED); // the following prints "BOOKED" System.out.println(seats.book(Seat.near(WINDOW).in(FIRST_CLASS))); // the following prints "null" because .book(Seat.near(AISLE).in(FIRST_CLASS))) was not stubbed System.out.println(seats.book(Seat.near(AISLE).in(FIRST_CLASS))); // the following verification passes because .book(Seat.near(WINDOW).in(FIRST_CLASS)) has been invoked verify(seats).book(Seat.near(WINDOW).in(FIRST_CLASS)) // the following verification fails because .book(Seat.in(SECOND_CLASS)) has not been invoked verify(seats).book(Seat.in(SECOND_CLASS)) Example
  10. Jenkins (Open source) Travis / Circle CI / Atlanssian Bamboo

    Performs testing on triggering actions like PR merge Automated reporting: Send email if build fails Auto publishing to play store Continuous Integration