Desta forma, a integração contínua se torna viável com base na utilização de testes automatizados. De acordo com Vidal (2017, p. 221), a automação dos testes deve ser realizada em níveis diferentes. O autor sugere que os testes manuais sejam feitos apenas em casos exploratórios, deixando que a maior parte do trabalho de testes seja realizada de forma automatizada. Além de suportar a integração continuada, esta estratégia fornece agilidade ao trabalho do time e ainda reduz os custos do projeto, pois, uma vez que o teste seja escrito, este pode ser executado tantas vezes quanto for necessário.
No cenário de integração contínua, os testes de aceitação, a serem realizados pelo cliente, mantêm-se presentes. Estes testes ajudam a delimitar o escopo das funcionalidades que estão sendo construídas pelo time de desenvolvimento, além de fornecer feedback para decisões a serem tomadas pelo time.
Como já mencionamos quando tratamos dos testes automatizados, também é importante que, em métodos ágeis, os ambientes de desenvolvimento, teste e produção sejam mantidos separados e com condições de infraestrutura adequadas. Isso garante que os ambientes se mantenham controlados, assegurando que o produto não fique fracionado e tenha a qualidade mantida.
Vidal (2017), ainda propõe a criação de uma massa de testes, conforme indica a Figura. Esta massa de testes, além de contribuir para a redução da carga de trabalho, fornece insumos importantes para o time quando for necessário executar testes durante a construção do produto.
De acordo com a Figura, deve-se selecionar no backlog, que reúne as histórias do usuário, as que devem ser implementadas na release. Casos de uso e cenários devem ser criados para as histórias selecionadas, que servirão de insumos para se definirem os casos de teste, formando a massa de testes. Quando forem aplicados os testes de aceitação junto ao cliente, deve ser criada uma massa de dados adequada para a sua execução.
Criação da massa de testes
Definida a massa de testes, é essencial o uso de uma ferramenta de integração contínua para executar os testes automatizados periodicamente, a fim de garantir que todos eles continuem passando, ou seja, funcionando adequadamente.
De acordo com Barbosa (2012), após a escolha da ferramenta de integração, deve-se informar à ferramenta
[...] o repositório no qual o projeto está armazenado (entende-se como repositório a URL em que o projeto está sob um sistema de controle de versão, como SVN, CVS, Git, Mercurial etc) e um conjunto de tarefas que devem ser executadas para garantir que a integração ocorreu com sucesso. Em geral, criam-se tarefas para a realização do build (quando necessário) e execução de um determinado tipo de teste. Por exemplo, se estamos desenvolvendo um projeto fictício chamado XPTO, criamos uma entrada na ferramenta chamada XTPO-Unit que, de tempos em tempos, irá baixar o código do repositório do controle de versão, executar o build e depois executar todo o conjunto de testes unitários existentes no projeto. Caso todos os testes passem, a integração ocorreu com sucesso; caso contrário, não.
Ainda segundo Barbosa (2012), algumas ferramentas de integração permitem a inclusão de plug-ins que fornecem serviços complementares como relatórios que informam quanto do código está coberto por testes, envio de mensagens por e-mail, informando ocorrência de eventuais falhas na integração etc.
As ferramentas automatizadas de integração contínua, na ocorrência de erro, disparam mensagens para os responsáveis, acusando uma integração mal sucedida. No caso de sucesso, também disparam mensagens informando que a operação foi realizada de forma bem sucedida. A isto se aplica um conceito chamado servidor de construção (build). Este servidor de construção atua como “juiz”, julgando ou considerando as alterações, validando-as quando detectado sucesso nos procedimentos. Em suma, integração contínua automatizada envolve a construção de um código e seu teste de forma automática, e em intervalos frequentes, em um servidor de integração.
Nenhum comentário:
Postar um comentário