-
Notifications
You must be signed in to change notification settings - Fork 57
Home
Welcome to the android-gradle-template wiki!
Travis has no build tools 20.0.0 yet, current i use a workaround referenced here https://github.com/travis-ci/travis-ci/issues/2470
- (done) working setup android studio + gradle + espresso + robolectric
- (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) ...
- ui test coverage (is done when novoda test plguin is updated)
- ui test screen shots with spoon, include dialogs
- 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
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.
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