Concrete Logo
Hamburger button

Como fazer Integração Contínua no Android – parte 5

  • Blog
  • 7 de Maio de 2014
Share

Hoje falaremos do famoso relatório de cobertura. Para quem chegou agora, vejam as outras partes desta série:

  • Parte 1: Apresentação e um pouco do histórico dos sistemas de build e IC no Android
  • Parte 2: Configuração das dependências e do ambiente
  • Parte 3: Criação do projeto inicial e mavenização
  • Parte 4: Criação do projeto de teste

Chegamos naquela parte polêmica. Cobertura de código. A solução de todos os seus problemas de qualidade de código? Certamente não. 100% de cobertura é garantia de não ter bugs no sistema? Claro… que não. Deve-se tomar muito cuidado com a cobertura, pois ela pode passar uma ilusão de que está tudo bem ou tudo ruim. Ou seja, se mal utilizada ela pode lhe causar mais problemas do que soluções.

Cobertor curto

Cuidado com o cobertor curto!

Qual o problema com a cobertura? Como garantimos que estamos fazendo as asserções corretas? Como explicar que um relatório de “Cobertura de Código” não é a maravilha que a gerência acredita ser? Enfim, não é o objetivo aqui explicar ou discutir a cobertura de código, mas apenas usá-la para exemplificar como o nosso processo de build pode agregar relatórios diversos agora que já o separamos da IDE como preconizamos no passo 1.

No Android geramos este relatório com o EMMA. Essa ferramenta se pluga na instrumentação de testes nativa do Android. O plugin android-maven-plugin que estamos usando já tem configurações específicas para o code coverage. Vamos aos passos para configurar nosso projeto (agora o projeto de exemplo está disponível num repositório público).

Como o EMMA funciona? Ele instrumenta o código. Ou seja, ele escreve bytecode (instruções de código) para executar antes e depois de cada método que você executa. Por isso vocês verão um WARNING grande no console dizendo que o pacote gerado NÃO DEVE IR PARA PRODUÇÃO!. O que acontece se for? Nenhuma guerra mundial, mas irá um pacote desnecessariamente maior e que pode ter um leve impacto de performance.

Vamos às configurações! Primeiro no nosso projeto main (o principal) acrescentaremos um profile de Maven chamado “emma”. Ele terá uma configuração extra para chamar essa instrumentação.

[code language=”xml”]
<profiles>
<profile>
<id>emma</id>
<build>
<plugins>
<plugin>
<groupId>com.jayway.maven.plugins.android.generation2</groupId>
<artifactId>android-maven-plugin</artifactId>
<version>${android-maven-plugin.version}</version>
<configuration>
<!– emma start –>
<emma>
<enable>true</enable>
<classFolders>
${project.basedir}/bin/classes
</classFolders>
<outputMetaFile>
${project.basedir}/target/emma/coverage.em
</outputMetaFile>
<filters>-android.*</filters>
</emma>
<!– emma stop –>
<dex>
<noLocals>true</noLocals> <!– must be set for emma –>
</dex>
</configuration>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
[/code]

Esse profile contém apenas uma sobrescrita da configuração do plugin. Nessa nova configuração ligamos o EMMA, dizemos qual é a pasta das classes compiladas, onde será guardado o arquivo .em (contém o conjunto de metadados que o EMMA gera em sua instrumentação) e opcionalmente colocamos os filtros de pacotes e classes que não queremos incluídos no relatório de cobertura. A nomenclatura de filtros é bem simples, mas não está na documentação do plugin. Então segue um resumo: basicamente pode-se excluir ou incluir pacotes utilizando os sinais + ou -. Além disso no nome do pacote aceita-se asteriscos para incluir todas as classes e subpacotes.

Feito isso, para chamar a compilação com o EMMA basta executar:

[code language=”shell”]
mvn clean install -Pemma
[/code]

Repare no output e veja se há o aviso do EMMA sobre o pacote em produção. Fora isso a execução será como as anteriores.

Agora para a configuração do nosso projeto de teste:

[code language=”xml”]
<profiles>
<profile>
<id>emma</id>
<dependencies>
<dependency>
<groupId>emma</groupId>
<artifactId>emma</artifactId>
<type>jar</type>
<scope>compile</scope>
<version>${emma.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<!– read project properties ( can be build.properties or default.properties
Most important property is tested.project.dir – should be path to project
which we want measure coverage –>
<file>project.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.jayway.maven.plugins.android.generation2</groupId>
<artifactId>android-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<test>
<!– Run test with flag "-w coverage true" this is need for generate
coverage.ec file, result file –>
<coverage>true</coverage>
<createReport>true</createReport>
</test>
</configuration>
<!– need for pull coverage.ec file and move to tested project –>
<executions>
<execution>
<id>pull-coverage</id>
<phase>post-integration-test</phase>
<goals>
<goal>pull</goal>
</goals>
<configuration>
<pullSource>/data/data/br.com.concretesolutions.exemplo.ic/files/coverage.ec</pullSource>
<pullDestination>${tested.project.dir}/target/emma/coverage.ec</pullDestination>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<!– Plugin for generate report – if you want use sonar you could skip
this raport plugin –>
<groupId>org.sonatype.maven.plugin</groupId>
<artifactId>emma4it-maven-plugin</artifactId>
<version>1.3</version>
<configuration>

<metadatas>${tested.project.dir}
/target/emma/coverage.em,${tested.project.dir}/src/</metadatas>
<instrumentations>${tested.project.dir}
/target/emma/coverage.ec</instrumentations>
<reportDirectory>${tested.project.dir}
/target/emma/</reportDirectory>
<baseDirectory>${tested.project.dir}/target/</baseDirectory>
<formats>xml,html</formats>
</configuration>
</plugin>
</plugins>
</reporting>
</profile>
</profiles>
[/code]

 

Aqui temos mais detalhes. Primeiramente temos uma dependência que só é acrescentada neste perfil. Trata-se do próprio EMMA. Depois temos mais um plugin no build que lê o arquivo project.properties. ISTO É FUNDAMENTAL! No project.properties do seu projeto de teste deve haver uma propriedade chamada “tested.project.dir” que terá o NOME da pasta do projeto testado. Só isso. Se não houver o EMMA se perde.

Ainda dentro do build, também sobre-escrevemos o plugin do Maven. Nesse caso precisamos passar para a configuração de onde vamos pegar os resultados da cobertura. Após o build temos um plugin de reporting que gerará nosso HTML.

De novo, para executar primeiro o build e depois a geração do relatório só executar os comandos:

[code language=”shell”]
mvn clean install -Pemma

mvn org.sonatype.maven.plugin:emma4it-maven-plugin:1.3:report
[/code]

Se tudo der certo, pronto! No seu projeto main deverá haver dentro do target o relatório do emma. No próximo passo vamos ver como configurar tudo isso no JENKINS finalmente! Aguardem cenas do próximo capítulo! E se ficou alguma dúvida até aqui, deixe nos comentários.