Usos práticos da suíte de testes - Jacoco e CI

Confira nossa série sobre testes automatizados no Android: Por que devo testar minhas aplicações Testes automatizados no Android Ambiente...

Data de publicação: 19/11/2019
Desenvolvimento Android

Confira nossa série sobre testes automatizados no Android:

Usos práticos da suíte de testes

Estamos chegando ao fim da jornada e depois de todo esse processo, já temos muito mais confiança para trabalhar em nosso código com testes unitários e de tela para nos auxiliar. Aprendemos que os testes automatizados nos permitem validar que nossas modificações não quebram o funcionamento esperado do projeto. Isso nos permite fazer modificações com muito mais tranquilidade e segurança.

Mas aí fica a dúvida: depois de termos todos nossos testes unitários e de tela implementados, como podemos de fato nos beneficiar da nossa suíte de testes?

Relatórios de cobertura de testes — Jacoco

Uma ferramenta essencial para um projeto Android com testes automatizados implementados, é o Jacoco. Basicamente, essa ferramenta faz uma análise de cobertura de testes, apontando não só a porcentagem do codebase coberto pelos testes, mas ainda mostra em cada arquivo, quais linhas estão cobertas e até mesmo, quais possíveis fluxos em cada trecho de código estão cobertos.

Na imagem abaixo, podemos ver em verde, as linhas que estão cobertas por teste. Em amarelo, temos as linhas que estão cobertas parcialmente, ou seja, um ou mais possíveis fluxos não foram testados para aquele trecho. E em vermelho, temos as linhas que não foram cobertas por nenhum teste.

Os dados de cobertura de testes, apesar de não serem nenhuma garantia absoluta, podem ser considerados um ótimo indicador da saúde de um projeto. O Jacoco gera relatórios muito úteis para calcular essa métrica.

Porém, mais do que esse número simbólico gerado, o principal benefício de usar uma ferramenta como essa no projeto, é a possibilidade de verificar quão bem testados estão cada arquivo do projeto.

Com os relatórios gerados pelo Jacoco, fica muito mais fácil identificar cenários descobertos em nossos testes, nos ajudando a garantir a melhor cobertura possível.

Portanto, mais do que apenas uma ferramenta para geração de métricas de cobertura de testes, o Jacoco é uma ótima arma para os desenvolvedores durante o desenvolvimento de testes.

Testes rodando de forma automatizada — CI

O principal objetivo dos testes em um projeto, é oferecer confiança para que seus desenvolvedores trabalhem livremente, certos de que suas modificações não impactam no funcionamento esperado do projeto. Mas apenas tê-los desenvolvidos, ainda não é o suficiente.

A forma mais simples seria simplesmente que os desenvolvedores executassem os testes antes de subir cada modificação, verificando se tudo segue funcional. Isso dificilmente funcionaria na prática e a tendência seria de que simplesmente os testes deixassem de ser usados.

Mas então, como tornar esse processo automatizado de fato como comentamos inicialmente?

É aí que entra o principal parceiro de uma boa suíte de testes: O CI.

CI é a abreviação para Continuous Integration, que basicamente é a prática de automatizar a integração de modificações de código de múltiplos contribuidores em um mesmo projeto, garantindo o bom funcionamento do código antes de integrá-lo de fato.

Integração entre CI e versionadores de código

Com algumas rápidas configurações, um CI pode impedir por exemplo, que uma modificação entre em uma determinada branch, se algum teste falhar, garantindo a estabilidade do código compartilhado pelos desenvolvedores.

O CI consegue ir mais além e até mesmo enviar para o seu versionador de código os resultados dos testes executados. Essa configuração geralmente é muito simples e se dá por meio de integrações entre as ferramentas de versionamento e as de CI.

As ferramentas de CI como o Jenkins por exemplo, geralmente oferecem os chamados webhooks, que basicamente são urls que nos permitem iniciar pipelines dentro do CI, externamente. E os versionadores como o Gitlab, nos permitem configurar quais webhooks serão executados em cada “evento” ocorrido em uma branch, como o push de um novo commit por exemplo.

Na imagem acima, podemos ver um exemplo onde após um merge request ser aberto no gitlab, duas pipelines foram executadas no Jenkins via webhook. Os status de cada uma delas são recebidos e exibidos dentro do painel do gitlab e devido a falha de uma das pipelines, o desenvolvedor não conseguirá fazer o merge das modificações antes de corrigir os testes quebrados.

Bom pessoal, chegamos ao fim da nossa série sobre o mundo dos testes automatizados no Android. Obviamente, esta é apenas uma breve introdução do que é possível ser feito para automatizar os testes em projetos de aplicativos Android. Espero ter no mínimo te deixado curioso para aprender um pouco mais sobre testes. Independente da plataforma, os testes automatizados são parte fundamental para facilitar a vida dos desenvolvedores e garantir a qualidade dos projetos. Até a próxima e happy coding! 😉

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

oito − cinco =

Posts relacionados

  1. Sobre a Dextra

    Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes.

  2. Categorias

Scroll to top