I’ve recently read great article telling how to improve quality and syntax of your Android code by Vincent Brison. It presents how to use tools like Checkstyle, Findbugs, PMD, and Android Lint for Static Code Analysis in Android project. Static Code Analysis allows us to keep consistency of the source code style and helps us to find errors, warnings, possible bugs, bottlenecks and ways to improve the projects. I highly recommend to use tools like those mentioned.
Visit repository at: https://github.com/vincentbrison/vb-android-app-quality. The most important files are:
We can run analysis by executing the following command:
./gradlew check Besides that, we can run each command like
lint separately if we want to. In addition, when we build the project with command:
check command will be executed as well, because of the following line in
check.dependsOn 'checkstyle', 'findbugs', 'pmd', 'lint' After that, we can find output with our reports in directory:
app/build/reports/. Of course, we can customize output directory and names of the report files. In default configuration,
check command with generate reports in HTML format. Only output from the
checkstyle operation will be generated in XML format. We can customize
lint, to generate XML reports instead of HTML reports in
Sensitivity of the build
We can customize rules of the Static Code Analysis tools in restrictive and non-restrictive way. In
pmd task, we can set
ignoreFailures attribute as follows:
ignoreFailures = false When it’s set to
false, tasks will only generate reports, but when we set it to
true, build will fail, when at least one error will be found. In
lint task, we can customize attribute
abortOnError as follows:
abortOnError true It will literally abort the build, when any lint error occur. Warnings will be ignored. When we want to ignore errors, we can set this attribute to
Static Code Analysis on CI server
When we want to perform Static Code Analysis on CI server, we can do it easily from the command line interface. If we want to automatically collect and analyze reports generated by mentioned tools, we should generate them in XML format instead of HTML, so they can be parsed by appropriate plugins. Mentioned tools can be easily integrated with Jenkins CI server. We need the following plugins:
After installing those plugins, we can define post-build actions in our Jenkins Job, provide paths to the appropriate XML reports and then we can view results of the reports and trend graphs directly from web panel of our Jenkins server. Exemplary trend graphs looks as follows:
If we have unit tests in our project, we can also generate test reports and monitor test trend. In the chart below, failed build don’t have generated test reports that’s why chart may look strange. In addition, number of tests was decreased, because they were migrated from JUnit3 to JUnit4. In JUnit3 for some reason each test case is treated as an additional unit test. JUnit4 report shows real number of tests.
In every build, we can browse generated reports and their details.
I really recommend to use Static Code Analysis tools and reporting plugins on CI in the projects, because they will increase quality of the code really fast and will allow to eliminate many errors before shipping the application.