Testing component in Android App SDLC? -

"automated testing integral part of development lifecycle."

in android app proejcts we've implemented mvp, rx retrofit , content provider/sqlite, dagger. every android apps have server communication, storing data in local database, complex ui naviagtion drawer , recycler view etc, , difficult navigation flow of application.

what want achieve?

• few test cases should tested every time before deliver apk client or release on play store?(20-30% automate testing)
• list of test cases of business logic, can not auto tested because whatever reason complex ui, navigation flow etc (40-60% manual testing)
• continuous integration

based on above, there few questions,

• what test in auto , manual, how decide that?
• in automate testing, test in mvp - model-view-presenter layers?
• what kind of general business logic should auto test mobile apps - registration, login, forgot password, update profile etc?
• what type of testing should perform android apps - unit testing, functional testing, integration testing, manual testing, performance testing, regression testing
• which tool use - android testing support library, espresso, uiautomator, robotium, roboelectric, appium, selendroid, mockito, junit

(feel free improve check list don't know best practices testing module in sdlc android mobile app.) asked, here.

some answers questions:

• auto vs. manual: once design/dev cycles have settled, automated tests should part of code delivery before releasing. trigger here include ui testing in definition of done on stories before they're shipped. android, simple espresso tests cover new functionality.

• mvp layer testing...unit test presenters , ui test views. covers in models doesn't work because model changes done in isolation of 2 layers. high unit coverage in presenter helps balance how ui test written. see this article in-depth tutorial.

• business logic: @ least, tasks on critical paths users take accomplish key goals (i.e. revenue stream, basic adoption). yes, includes registration, login, , password features...but might not cover preferences/configurations , effects.

• type of testing: each type tests different layers/aspects of application, ask "what details in layers of app should care about"?

  • unit basic code validation, yes that, always. that's basic dev efficiency 101 there. high code coverage helps catch bugs early.
  • integration: yes, , depends on how complicated app is, testing app with/without dependencies helps isolate who's @ fault when test fails.
  • functional tests (ui tests): yes, simple interactions or complete workflow, it's how users work app. functions of app can't tested without going through set of other steps. again, align actual usage , business expectations. map amount of work here reality, usage metrics, impact on revenue, etc.
  • performance: hard, , there different schools of thought. see performance 'checks' along way necessary, full performance testing cycles impede development unless there's high degree of maturity , process in team/org.
  • regression: don't leave regression huge task towards end! smaller sets of regression informed changes you've made reduce number of defects caught in late-cycle regression testing. earlier means smaller, , don't forget we're dealing fragmented android ecosystem multiple devices/platforms/conditions needs included in regression strategy!

• tools: you've pretty nailed current toolchain. android ui testing, espresso/dagger/mockito huge win. keep these types of tests small , focused. end-to-end testing, appium still best friend, there things can't (like visual validation , popups) you'll need seek beyond them automate.

also, while understand statement "can not auto tested because whatever reason", think that's big red flag , details matter lot. the choice of auto vs. manual should business decision how achieve velocity goals, not technical limitations , shortfalls. hear time customers until realize right tech enables them achieve level of automation that's right them.

there 2 pieces of research assisted year think conversation:

1. expanding quality build cycle
2. improving app quality @ build-time

hope , research above helps work.