Medición de la calidad del código de la aplicación de Android con Sonarqube y Jacoco en 2019

Hola Habr!

Mi nombre es Artyom Dobrovinsky, trabajo como desarrollador de Android en FINCH .

Una vez, después de un par de pintas con un colega de una compañía que está colocando anuncios para vender MIG y mosquitos llamados Igor, comenzamos a discutir analizadores de código estático en CI (y qué más discutir). Se expresó la idea de que eran geniales de usar, pero solo después de que hubo confianza en la confiabilidad lógica del código. En otras palabras, puede pensar en el estilo de código solo después de escribir todas las pruebas.

Decidí escuchar a mi colega y pensé en cómo calcular la escala del desastre para aplicaciones improvisadas. La vista cayó sobre Sonarqube y Jacoco. El proceso de conectarlos para proyectos de hello-world es elemental. Conectarlos a un proyecto de Android, dividido en módulos, ya es más difícil. Para ayudar a los interesados, este artículo fue escrito.

Habré ya tiene una muy buena traducción del tutorial sobre el uso de Sonarqube, pero es de 2016, algo está desactualizado allí, no hay kotlin y solo encuentro que la generación de informes para todos los buildType es redundante.

Un poco sobre bibliotecas, para aquellos que no están familiarizados con ellas.

Sonarqube es una plataforma de código abierto para la inspección continua y la medición de la calidad del código. Le permite seguir la lucha contra la deuda técnica a lo largo del tiempo (es genial ver que la deuda técnica está ganando, y no puede hacer nada al respecto). Sonar también supervisa el código duplicado, las vulnerabilidades potenciales y la excesiva complejidad de las funciones.

Jacoco es una biblioteca gratuita para calcular la cobertura de prueba de un proyecto en Java. Pero con Kotlin haremos sus amigos.

Cómo conectar Sonarqube y Jacoco

En build.gradle del módulo raíz, agregue el siguiente código:

apply plugin: 'android.application' apply plugin: 'org.sonarqube' sonarqube { properties { property "sonar.host.url", "%url   sonarqube%" property "sonar.login", "%%" property "sonar.projectName", "% %" property "sonar.projectKey", "%  %" property "sonar.reportPath", "${project.buildDir}/sonarqube/test.exec" property "sonar.projectBaseDir", "$rootDir" property "sonar.sources", "." property "sonar.tests", "" property "sonar.coverage.exclusions", "**/src/androidTest/**, **/src/test/**" property "sonar.coverage.jacoco.xmlReportPaths", fileTree(include: ['*/*/jacoco*.xml'], dir: "$rootDir/app/build/reports/jacoco").collect() } } 

sonar.reportPath : indica dónde debe colocar Sonar el informe para un análisis más detallado.
sonar.projectBaseDir especifica la carpeta en la que se iniciará el análisis inicialmente; en nuestro caso, este es $ rootDir, la carpeta raíz del proyecto.
sonar.coverage.exclusions enumerando excepciones para contar la cobertura, donde ** es cualquier carpeta, a * es cualquier nombre de archivo o resolución.
sonar.sources es la carpeta de origen.
sonar.tests es una línea vacía aquí para que Sonarqube también pueda analizar las pruebas.
sonar.coverage.exclusions : excluimos las pruebas del análisis de cobertura de pruebas.
sonar.coverage.jacoco.xmlReportPaths : mediante el método collect() recopilamos informes de Jacoco para calcular la cobertura de la prueba.

Para activar Jacoco, es mejor crear un archivo jacoco.gradle y escribir toda la lógica necesaria allí. Esto ayudará a evitar abarrotar el otro build.gradle.

Para no registrar a Jacoco en el build.gradle de cada subproyecto, prescribimos su inicialización en el cierre de los subproyectos. En reportsDirPath para submódulos, especifique la carpeta raíz. A partir de ahí, Sonar tomará todos los informes de Jacoco.

 subprojects { apply plugin: 'jacoco' jacoco { toolVersion = '0.8.5' def reportsDirPath = "${project.rootDir}/app/build/reports/jacoco/${project.name}" reportsDir = file(reportsDirPath) } } 

En el mismo archivo, escribimos una función para configurar Jacoco.
Esta función es excelente, así que primero la traeré y luego explicaré lo que está sucediendo en ella.

 def configureJacoco = { project -> def variantName = project.name project.tasks.create(name: "getJacocoReports", type: JacocoReport) { group = "Reporting" description = "Generate Jacoco coverage reports for the $variantName build." reports { html.enabled = true xml.enabled = true } def excludes = [ '**/R.class', '**/R$*.class', '**/BuildConfig.*', '**/Manifest*.*', '**/AndroidManifest.xml', '**/*Test*.*', 'android/**/*.*', 'androidx/**/*.*', '**/*Fragment.*', '**/*Activity.*', '**/*Api.*', '**/injection/**/*.class', '**/ui/**/*.class', %  build- % ] def javaClasses = fileTree(dir: "${project.buildDir}/intermediates/javac", excludes: excludes) def kotlinClasses = fileTree(dir: "${project.buildDir}/tmp/kotlin-classes", excludes: excludes) classDirectories = files([javaClasses, kotlinClasses]) sourceDirectories = files([ "${project.projectDir}/src/main/java", "${project.projectDir}/src/main/kotlin", ]) executionData = files(fileTree(include: ['*.exec'], dir: "${project.buildDir}/jacoco").files) } } 

Creamos la tarea getJacocoReports , el grupo "Informes". Los informes se proporcionarán en formatos html y xml. Se analizarán todos los archivos, excepto los incluidos en la matriz exclude. Además de los archivos Androyd generados, decidí excluir del análisis todos los fragmentos y actividades, las interfaces de actualización, el paquete con DI, las vistas personalizadas y el código de la biblioteca.
Quizás esta lista cambie con el tiempo.

classDirectories : una indicación de dónde buscar el código para el análisis. Incluimos archivos java y kotlin aquí.
sourceDirectories : especifique dónde buscará Jacoco los archivos fuente.
executionData : como en el caso de Sonar, una indicación de dónde se generará el informe para calcular la cobertura.

También en jacoco.gradle necesita agregar su configuración para todos los módulos usando la función anterior:

 allprojects { project -> configureJacoco(project) project.tasks.withType(Test) { enabled = true jacoco.includeNoLocationClasses = true } } 

Y una tarea para recopilar los informes generados:

 task getJacocoReports() { group = "Reporting" subprojects.forEach { subproject -> subproject.tasks.withType(JacocoReport).forEach { task -> dependsOn task } } } 

Ejecutando Sonarqube a través de la línea de comando

./gradlew % % && ./gradlew jacocoAggregateReports && ./gradlew sonarqube simplemente: ./gradlew % % && ./gradlew jacocoAggregateReports && ./gradlew sonarqube . Los comandos se ejecutan a través de && , porque la ejecución debe interrumpirse si el paso anterior no tuvo éxito.

Lo que sucede en el comando anterior:

1. Primero, ejecute las pruebas (al mismo tiempo generamos todos los archivos necesarios en la carpeta de compilación).
2. Generar un informe Jacoco.
3. Lanzamiento Sonarqube.

Luego debe ir al sitio, fallar en el proyecto y observar la escala del desastre. La página del proyecto muestra el resultado de la última verificación.

Con Sonarqube, la idea del estado del proyecto se está volviendo mucho más completa. Es más fácil ajustar la acumulación de deuda técnica que asumir desarrolladores novatos (en cada objeción, Sonarqube da un argumento por el cual no se acepta escribir de esa manera; leer estas explicaciones puede ser muy útil), y simplemente: el conocimiento es poder .

¡Eso es todo, amigos!

Pregunta a los lectores: ¿qué utilizan para analizar el código y medir la cobertura de la prueba? ¿Ves el punto en absoluto?