How to build quality Android Apps - DroidconVN 2017

Practices to build quality Android apps including
- Testing
- Architecture
- Static code analysis
- CI

Transcript

1. HOW TO MAKE QUALITY ANDROID APPS Hai Nguyen Technical Lead – CBA Digital Solutions @minhhai8507
2. 2 What defines quality of an app? Ø No(less) bugs Ø Maintainability Ø Scalability Ø Performance Ø Code smells Ø Vulnerabilities Ø …
3. 3 How to improve the quality? Ø Testing Ø Unit test Ø Automation test Ø Architecture Ø Static code analysis Ø Code review Ø Continuous integration Ø Culture
4. 4 Why Android so hard to write unit test? Ø Android framework dependencies Ø Tight coupling Ø Slow start-up and execution time Ø Run on real device or emulator
5. 5 How to make unit test easier in Android Ø Remove the dependency with Android framework Ø Loose coupling, separation of concerns Ø Dependency Injection Ø S.O.L.I.D Ø Architecture patterns Ø MVP Ø MVVM Ø Redux Ø Riblets Ø …
6. 6 We choose MVP Android OS View Presenter Model Ø View as dump as possible Ø All the logics are in Presenters Ø Models are basically POJOs
7. 7 View Presenters Business rules/ Use Cases Repository Database API Stream Subscriber<T> Subscriber<T> Observable<T>
8. 8 How it looks like?
9. 9 What else can we test? Ref: https://martinfowler.com/bliki/TestPyramid.html
10. 10 Automation test Ø Automation frameworks Ø Appium for Android and iOS Ø Calabash for Android and iOS Ø MonkeyTalk for Android and iOS Ø Robotium for Android Ø Selendroid for Android Ø …. Ø Automated Ø Run on multiple devices Ø Detects UI and functional bugs Ø Requires coding skills
11. 11 CBA Solution's Automation Framework Ø Created our own automation framework bases on Appium Ø Use extend reports
13. 13 Code smells, coding style… Ø Detect bugs before the code get merged Ø SonarQube Ø Findbugs Ø PMD Ø Coding convention Ø Style check
14. 14 Why we need static code analysis? Ø Detecting potential bugs, Ø Detecting introduced vulnerabilities, Ø Pointing out duplicated code, Ø Detecting design flaws, Ø Enforcing coding standards, Ø Detecting dead code, Ø Measuring technical debt, Ø Providing an overall view of the project health.
15. 15 Style Check Analyses pure source code without any major preprocessing (simple AST tree created by Checkstyle). As a consequence it is very fast. Ø Naming conventions, Ø Headers, imports, Ø White spaces, formatting, Ø Javadoc comments, Ø Good practices, code conventions, Ø Method parameters, Ø Cyclomatic complexity, Ø Any regexp.
16. 16 Findbugs Findbugs is a program which uses static analysis to look for bugs in Java code. Analyses byte code. Requires compilation. As a consequence, rules are able to access information not only about the currently analysed class.. Ø Possible bugs, Ø Design flaws. Ø Bad practices, Ø Multithreaded correctness, Ø Code vulnerabilities.
17. 17 PMD PMD is a source code analyzer. It finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, and so forth. Analyses AST (Abstract Syntax Tree) generated by JavaCC. Does not require compilation. More advanced checks can be implemented, but still limited to one class. Ø Possible bugs, Ø Dead code, Ø Duplicated code, Ø Cyclomatic complexity, Ø Overcomplicated expressions, Ø And in fact everything that Checkstyle is capable of.
18. 18 Gradle task
19. 19 Fail fast If bugs/defects are inevitable, how to detect them as soon as possible? è Continuous Integration is a software development practice where members of a team integrate their work frequently. Each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. Martin Fowler
20. 20 CI tools Ø Jenkins Ø TeamCity Ø Travis CI Ø Go CD Ø Bamboo Ø Circle CI Ø Codeship Ø …
21. 21 A good build pipeline Coding SCM Push Build Unit Test Code Coverage Style Check Sonar check Acceptance Test JFrog
22. 22 Code review
23. 23 Engineering Guild ØPurpose: o Sharing knowledge o Engineering Practices o Innovation ØValues o Selflessness o Passion o Communication Ø Innovative ideas from the guild o Hercules o Achilles – the mock service o Poseidon – GA is very simple
24. 24 Recap ØAutomate the testing as much as possible ØChoose a good architecture works for your team ØUse static analysis tools ØFail fast ØCollaboration ØBuild an engineering culture ØSample code :https://github.com/hai-nguyen/Impala