Home

Welcome to the android-gradle-template wiki!

Milestones

1. (done) working setup android studio + gradle + espresso + robolectric
2. (done) extended app sample with database access

• (done) test automation with code coverage
• (done) decent test coverage with unit, component and acceptance tests
• (done) http calls with android annotations + wiremock + improve rest communication http://android-restful-pattern.blogspot.de/ https://github.com/posco2k8/rest_loader_tutorial
• (done) 3 week journey to USA west coast
• (in progress) update dependencies like build tools
• (plan) more component tests
• (plan) more acceptance tests
• (plan) measure memory usage, i believe there is a memory leak
• (plan) fragment activity example with unit, component and acceptance tests
• (plan) example what i mean with the experimental acceptance test with robolectric
• (plan) ...

Features wish (or just ideas)

• ui test coverage (is done when novoda test plguin is updated)
• ui test screen shots with spoon, include dialogs
• in app event based communication https://github.com/greenrobot/EventBus
• collect all test reports nicely
• all nice tools from Quality-Tools-for-Android (pmd, checkstyle, ..)
• improve adapter handling with https://github.com/excilys/androidannotations/wiki/Adapters-and-lists
• rest communication genrated with AndroidAnnotations
• json mapping object generated with jsonschema2pojo
• test server communication with wire mock (for component test and ui tests)
• generate database content at same time like android annotations
• in application communication events with Otto
• package-by-feature instead of package-by-layer
• Sonar for code statistics
• follow more best practices (use string.xml, ...)
• RoboCoP + SQLiteCipher
• MVVM pattern with android-binding
• There are many more interesting libraries out http://www.appbrain.com/stats/libraries/dev
• rest error handling
• try robolectric + espresso solution at https://github.com/JCAndKSolutions/android-unit-test *code coverage with Cobertura (it has a line-execution counting feature which JaCoCo lacks and it desirable)

Test variants

unit test Test with mocks for all class dependencies. For testing direct database operations i don't like to mock the real database. Database is fast enough for unit tests and writing cursor mocks need much effort. Database tests are done here too.

component test Put app components under test. It's your decision, what you call a component. Good approaches maybe Activities, Fragments, (any other ideas?), ...

experimental For apps designed with single activity to handle all fragments. Try writing tests as component test like you will write they in espresso. This should work and is very fast, but not suggested by google coding guides and not from the robolectric programmer.

acceptance tests Instrument your app with espresso to show that your app may handle the basic work flows correctly on one or all your device variants.

See also my inspiration sources

Quality-Tools-for-Android

deckard-gradle

android-tdd-playground

Project structure (need rewrite to have a feature oriented structure)

AndroidSample

• src/main/java/com/example/
  • activities activity classes
  • adapters data adapters with cursor loader
  • fragments fragment classes
  • json model classes for rest communication
  • managers wraps content provider usage
  • rest rest communication clients
  • receivers
  • services
  • viewmodel model classes for your views
• src/gen/com/example/
  • database (generated) database tables and helpers
  • provider (generated) provider for your database content
  • model (generated) helper classes to access cursor content
• src/test/java/
  • com/example tests with espresso
• build/source/apt//
  • com/example (generated) classes with AndroidAnnotations