A importância de testes e integração contínua em sua aplicação

A elaboração de testes, assim como sua codificação, é uma das etapas da produção de software geralmente mais burocrática e que, de maneira geral, não é uma das tarefas preferidas por desenvolvedores. No entanto, testes são essenciais para garantia de bom funcionamento de uma aplicação, e é importante que engenheiros de software não só saibam atuar nessa parte, como entendam os principais conceitos. Esses serão abordados nesse texto, enquanto a parte de código fica para uma outra ocasião.

Os 7 princípios de teste

1. Um teste pode mostrar a presença de defeitos, mas não apontar defeitos não garantirá a ausência deles. Mesmo testes com alta taxa de cobertura não serão capazes de prever certos defeitos possíveis em sistemas tão complexos como os atuais na indústria. Teste não é garantia de que não há defeito.

2. Testes exaustivos são impossíveis: É impossível testar todas as possibilidades de um sistema. Além disso, testar todo um sistema pode ser desnecessário e gastar muitos recursos. Existem técnicas de testes seguras efetivas e garantam uma boa generalização.

3. O teste inicial economiza tempo e recursos financeiros: Com base na regra 10 de Myers, o custo da correção de um defeito tende a aumentar quanto mais tarde ele for encontrado. Os defeitos encontrados nas fases iniciais do projeto de desenvolvimento do software são mais baratos do que aqueles encontrados na produção. Portanto, iniciar uma aplicação com implementação de testes é uma prática a ser seguida.

4. Defeitos se agrupam:  O Princípio de Pareto afirma que 80% dos erros podem ser oriundos de 20% dos módulos da aplicação. Logo, quando tais áreas do sistema são identificadas, pode-se priorizar testes nas mesmas e dar a devida atenção. Basicamente é um princípio que observa a correlação entre os defeitos.

5. Paradoxo dos testes: Criar novos testes, porém com repetição, quando não há mudanças no sistema, não encontrará novos defeitos. Essa prática só fará sentido em caso de regressão, quando houve alteração de alguma funcionalidade do software.

6. Teste sempre dependerá de contexto: Teste sempre dependerá do ambiente no qual o software é aplicado. Quanto mais crítica a aplicação, maior a exigência da qualidade dos testes, quantidade e cobertura.

7. Ausência de erros é mera ilusão: Seguindo um pouco do princípio 1, nunca é possível afirmar que um sistema não tem erro. Teoriacamente é impossível provar que um produto de software não tenha defeitos. No entanto, isso não significa que deva-se buscar defeitos da aplicação de maneira demasiada

Níveis de teste (em ordem de hierarquia)

1. Teste de unidade: É um teste com objetivo de testar a menor parte do sistema (uma classe, método ou função). Não exige que o projeto esteja em uma etapa avançada, sendo um teste geralmente automatizado e criado pelo próprio desenvolvedor.

2. Teste de integração: É um teste com objetivo de validar a comunicação entre componentes de um sistema. Também desenvolvidos pelo próprio desenvolvedor do sistema sem a necessidade de um profissional testador. Devem ser testadas as funcionalidades que envolvem a integração de componentes. Podem ser feitos ao longo do processo de produção do software, conforme os componentes são construídos.

3. Teste de sistemas: Visa executar o software sob o ponto de vista do usuário final, varrendo as funcionalidades em busca de falhas em relação aos objetivos originais. Esses testes são realizados pela equipe de testes/QA da empresa, passando por cenários de acordo com os requisitos especificados da aplicação. É um teste realizado com a aplicação já codificada.

4. Teste de aceitação: Teste feito pelo usuário. Tem como objetivo executar o sistema sob ponto de vista do seu usuário final, para que o uso das funcionalidades apontem falhas ocasionalmente. É planejado e executado por um grupo restrito de usuários finais do sistema.

5. Teste Alfa: Semelhante ao teste de aceitação, porém com um grupo ainda menor de pessoas. É, de maneira geral, um teste realizado com o cliente do software.

6. Teste Beta: O grupo de pessoas é ainda maior. A aplicação é liberada inclusive para pessoas desconhecidas, porém seguindo determinado critério.

7. Teste de Regressão: Teste que pode ser realizado a qualquer momento. Ele consiste em reexecutar testes após alterações serem realizadas no sistema. O objetivo é verificar se tudo continua com o mesmo funcionamento ou se houve impactos em outras partes do sistema após ser aplicada alguma alteração no sistema. Costumam ser automatizados.

Regra 10 de Myers

Integração contínua

Após abordar um pouco dos conceitos mais fundamentais de teste, abordemos agora a integração contínua e dev ops. Dev Ops é uma abreviação de Development e Operations, isto é, desenvolvimento e operações. É a combinação das melhores práticas e ferramentas, que visa aumentar a habilidade de uma organização para entregar aplicações e serviços mais rápido do que processos de desenvolvimento de software tradicionais. O ciclo DevOps pode ser descrito como na imagem a seguir:

Ciclo Dev Ops

São tópicos de DevOps:

• Planning (Planejamento) da próxima iteração do desenvolvimento do produto.

• Building (Construção) do código

• Testing and deploying (Teste e implementação) do ambiente de produção

• Delivering (entrega) de atualizações do produto

• Monitoring and logging (monitoramento e exploração) do desempenho do software

• Gathering (reunião) de feedback com cliente

Resumidamente falamos de desenvolvimento, integração, teste, monitoramento, feedbacks, implementações operações de forma contínua. Vejamos abaixo algumas imagens sobre o tema

Ferramentas comum de integração contínua

Ciclo de vida CICD

Sugestão de ciclo de vida CICD corporativo

Para ter um bom ciclo de integração contínua e um projeto profissional bem estruturado, é interessante que sejam escolhidas ferramentas que contemplem cada ciclo da sua aplicação. Uma combinação de ferramentas que aprecio, principalmente quando trabalho como desenvolvedor Java é: Maven na fase de construção, códigos no GIT, deploy com nuvem AWS, também utilizando Docker quando especificado e orquestrando via Kubernets gerenciando a aplicação e deploy com Jenkins. Além disso, acho interessante algumas ferramentas que podem ser acrescentadas. Na etapa de testes, costumo utilizar o Jacoco para gerar um HTML bem interessante graficamente com a cobertura de testes da aplicação Java. Utilizar o SonarQube para garantia de qualidade de código é uma excelente proposta também. Além disso, acho interessante bastante rigidez com commits. Por meio do Jenkins é possível criar um git hook. Git hook é nada mais nada menos do que um critério pré commit, isto é, algo ao qual commit fica atrelado e só será realizado atendendo a tal condição. Acredito que eleve bastante a qualidade do código quando, por exemplo, se atrela hook à cobertura dos testes. Isto é, podemos exigir que para um commit ser validado, que haja 70% de cobertura de testes da funcionalidade implementada. Assuntos de integração contínua são extensos e poderia fazer um texto para cada um, o que fica para próximas postagens.