Utilizando SonarQube como sua ferramenta de Code Smells + Cobertura de testes unitários em projeto Android parte 1

Atualmente, em um projeto que estou trabalhando, surgiu a necessidade de realizar uma integração no Github Actions para coletarmos dados de cobertura de testes e code smells no projeto Android e nesta pequena série de posts irei explicar o passo a passo para a integração entre a ferramenta do SonarQube com um projeto Android dentro do Github Actions.

Por padrão da empresa, assumimos o SonarQube como ferramenta de análise e portadora dos dados que seriam utilizados para a análise de cobertura de testes unitários e possíveis Code Smells.

O que é Cobertura de Testes e Code Smells

Cobertura de testes por definição é a métrica que determina quanto o seu código em produção está protegido por cenários reais de regra de negócio/lógica aplicada. Essa métrica é utilizada por muitos programadores como uma análise de quanto o seu código está suscetível a falhas ou buracos de regra de negócio para qual elas foram implementadas. Caso tenha interesse, indico fortemente a literatura de Robert C. Martin (aka Uncle Bob) e sua experiência com testes e sua importância na vida de um programador.

Code Smells são por definição mais simplista, um código que pode gerar um problema futuro ou que não seja a melhor maneira de resolver um problema e que pode gerar impactos negativos na vida de um software ao longo do seu tempo de vida. Esses Code Smells podem ser códigos duplicados, arquiteturas mal aproveitadas, falhas de segurança entre outros pontos.

O SonarQube

O SonarQube é uma ferramenta amplamente difundida no mercado sendo referencia para diversas linguagens de programação como ferramenta detecção de CodeSmells e Code Coverage, aceitando do Java até C como linguagem para análise. Caso tenha interesse você pode ler mais sobre a ferramenta aqui.

Para alimentarmos os dados no SonarQube, você precisa realizar uma pré configuração estabelecida por eles para ter acesso a chaves de ambiente e chaves de projeto que serão a forma de autenticação que o seu projeto irá realizar com a ferramenta para enviar os dados de forma segura. Por padrão existem algumas chaves de forma de autenticação:

• projectKey: Chave do projeto que muitas vezes é o nome dado ao projeto dentro do SonarQube.
• host.url : Url do endereço web onde o seu servidor do SonarQube irá rodar, por padrão devemos criar uma máquina que irá manter essa instância para os reports e análise dos dados. Você pode ter N linguagens dentro desse host, não é obrigado manter um para cada linguagem de programação
• login : Token de autenticação única para a utilização de autenticação de acesso ao servidor. Esse token ele é mostrado somente uma vez no momento da criação do projeto. Cuidado para não perder ele.

O JaCoCo Test Report

O JaCoco (Java Code Coverage) é uma biblioteca de cobertura de código escrita em Java e que graças a interoperabilidade entre o Java e o Kotlin ela é possível ser utilizada para projetos com Kotlin para gerar os reports e dados de cobertura de testes. Para uma melhor compreensão da ferramenta sugiro você ler a documentação oficial aqui.

Configurando o JaCoCo

Como o projeto em questão era modularizado, nós utilizamos uma configuração de JaCoco para aproveitar sabermos se devemos realizar a coleta de dados ou não e como configuramos alguns dados padrões dos dados de report.

No código abaixo, podemos ver uma configuração base que utilizamos do JaCoco onde determinamos que tipo de arquivo de report desejamos, se desejamos ignorar o módulo analisado no momento, quais arquivos desejamos ignorar e se desejamos que a task do Gradle do JaCoCo dependa da task de testes do Gradle.

Arquivo com a configuração do JaCoCo

Configurando o SonarQube no Android

Após configurado o JaCoCo, o próximo passo é configurar a task do SonarQube dentro do projeto Android de forma que ao executar a task do Sonar ele gere esses reports e sirva também como balizador para saber se um código está coeso e sem quebras possíveis por falta de testes e/ou falhas na implementação.

Arquivo build.gradle do projeto Android com configuração do SonarQube

No arquivo acima, para todos os modulos dependentes do projeto eu aplico a configuração do SonarQube, desta forma eu “crio” a task de SonarQube para aquele modulo e determino que ela depende da task jacotoTestReport e que essa task deve rodar depois de um clean no projeto. Este clean serve para ter garantia de que, todos os formulários antigos foram removidos com as métricas de análise de código para que os novos estejam de acordo com o novo código implementado.

Dentro das propriedades, eu determino a linguagem padrão do projeto que neste caso é Kotlin, o diretório de algumas classes e principalmente qual é a ferramenta de geração de reports, no caso o JaCoCo.

Próximos passos

No próximo post, irei me aprofundar no envio desses reports para o servidor e como automatizar isso com base no Github Actions.

Até lá.