Por que eu devo ler este artigo:No desenvolvimento de qualquer projeto de software, a utilização de testes se faz necessária. A Integração Contínua permite que o código seja compilado e testado durante o desenvolvimento, fazendo com que os erros sejam encontrados mais facilmente pelos desenvolvedores.

Ao longo desse artigo, veremos o que são e como implementar os testes unitários na integração contínua, bem como uma básica implementação da cobertura de código. Nesse artigo teremos uma implementação da integração contínua em algum lugar entre o quinto e sexto ciclos de implementação, dentro dos sete ciclos da integração contínua, que serão resumidos brevemente.

A integração contínua (ou Continuous Integration, CI) é talvez a principal ferramenta no desenvolvimento de grandes projetos. A sua implementação, entretanto, não é tão simples como possamos perceber. A integração contínua depende de várias ferramentas e ideias que precisam ser muito bem colocadas de forma conjunta. Para isso, é preciso que haja um conhecimento de todos os processos que envolvem essa implementação, bem como detalhes importantes, como a participação do time de desenvolvedores.

As vantagens que a integração contínua traz no desenvolvimento de software são muito grandes. Primeiramente, vale ressaltar que se trata de uma opção que praticamente elimina todas as modificações de última hora, que são grandes responsáveis por atrasos em projetos de software.

Entretanto, é preciso ter cuidado na implementação, uma vez que ela precisa ser gradual, e não aplicada de forma indiscriminada. Essa aplicação indiscriminada pode criar uma resistência entre a equipe de desenvolvimento, fazendo com que a integração contínua não funcione da maneira que se deseja. Por isso, é preciso estar atento aos sete ciclos de implementação:

1º) Ciclo inicial, todos os passos de construção e integração do software realizados manualmente.

2º) Há um servidor de build (SCM) e algum nível de automatização desses builds.

3º) O servidor já é capaz de aplicar alguns testes básicos ao código, além de o build contínuo já estar sendo aplicado (toda vez que o código é comitado no SCM).

4º) Aplicação da verificação de qualidade de código (QA).

5º) A integração contínua já começa a se encaixar nas práticas de teste (TDD).

6º) Os principais testes já estão incluídos na CI, bem como ferramentas de relatórios e comunicação entre os membros da equipe.

7º) A integração contínua está integralmente implementada dentro da rotina da empresa, com tudo que se espera dela.

A implementação da integração contínua diz respeito também às ferramentas escolhidas. É preciso que haja uma boa escolha tanto do servidor SCM como do servidor de integração contínua propriamente dito que serão utilizados. Em servidores SCM, as principais opções do mercado são o SVN (ou Subversion) e o Git.

Em termos de servidores de CI, podemos apresentar o CruiseControl.NET e o Hudson, opções open source, e o TeamCity, este pago. A opção pelo TeamCity pode se explicar pelo fato de que ele traz suporte, como é natural em qualquer software pago. Porém, é possível implementar a integração contínua com pouco ou nenhum gasto.

Ao longo desse artigo iremos apresentar os testes unitários e a cobertura de código ao leitor, e veremos como eles se comportam dentro do sistema de integração contínua. Ao final, iremos ter nos aproximado do final da implementação da integração contínua, chegando em algum ponto entre o quinto e sexto ciclos, faltando apenas incorporar elementos de qualidade de software e testes finais.

Testes Unitários e Cobertura de Código na Integração Contínua

Inicialmente, precisamos enfatizar um detalhe muito importante: o desenvolvimento de software, atualmente, é baseado em testes. Na integração contínua, isso não é diferente. Quando realizamos a implementação do sistema, portanto, precisamos ter em mente esses detalhes. Além disso, precisamos notar que os testes precisam ser a prova de erros, evitando resultados continuamente ruins.

A importância de um bom conjunto de testes em um desenvolvimento baseado em IC é ainda mais importante do que quando estamos lidando com o desenvolvimento sem a tecnologia.

Primeiramente, vamos entender o funcionamento da integração contínua. Essa integração deve ser realizada em três etapas muito claras: o build, quando há um commit de uma nova funcionalidade no servidor; os testes unitários; e os testes de aceitação/integração. Esse terceiro ponto é um pouco mais complexo e não falaremos dele nesse artigo.

Além disso, ele é um pouco mais demorado e por isso não irá acontecer a cada commit. Os dois primeiros passos, entretanto, devem ser realizados a cada vez que um novo código é comitado no servidor, criando assim a integração de forma contínua, como o nome sugere. Esse funcionamento é mostrado na Figura 1.

Figura 1. Ordem de execução da integração contínua

Quando falamos em testes, o que pensamos é em garantir a qualidade do que está sendo criado. A questão é como fazer isso de forma simples e rápida, uma vez que a integração, para ser contínua, não pode levar muito tempo. Além disso, os testes automatizados que iremos incluir no desenvolvimento devem ser, de forma garantida, eficientes. Não podemos ter um teste que insiste em dar o resultado errado, o que pode comprometer totalmente a integração do software ao longo do desenvolvimento. O grande objetivo aqui é identificar erros rapidamente para que eles possam ser solucionados durante o desenvolvimento.

Vamos começar com o entendimento dos testes unitários. Os testes unitários são, basicamente, testes em que as unidades do programa são testadas, ou seja, os métodos que possuem algum tipo de retorno. O objetivo é testar a entrada e saída de dados de cada uma dessas unidades de acordo com o esperado.

Esses testes, veja bem, não são a solução para os problemas de desenvolvimento; eles não irão garantir que o software terá qualidade (BOX 1). Eles apenas irão garantir que aquele método, baseado no argumento de entrada, está oferecendo uma saída que é esperada.

BOX 1. Qualidade de software

O termo qualidade de software é muito subjetivo, o que abre uma margem muito grande para debates.

Afinal, o que é bom para um pode não ser bom para outro. Porém, em termos de q ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo