Muitos desenvolvedores enfrentam o desafio de garantir que suas features e fixes não causem falhas em outras partes do código. Mesmo que os frameworks mais recentes sejam projetados para promover a componentização, o isolamento e até mesmo paradigmas de programação, como a programação orientada a objetos, falhas ainda podem surgir infelizmente, essa é uma realidade. Então, qual é a solução para reduzir os riscos de falhas? A criação de testes automatizados.
Como, na prática, os testes automatizados funcionam? Explicando de maneira simples e com base nos conceitos do exame ISTQB – Teste Foundation, os testes são organizados da seguinte forma:
1. Test Suite 1:
1.1 Test case 1
1.2 Test case 2
2. Test Suite 2:
2.1 Test case 1
2.2 Test case 2
Com base nessa estrutura organizacional, podemos definir que:
Test case: é uma condição específica que será verificada no sistema.
Test Suite: é um conjunto organizado de casos de teste reunidos para serem executados em conjunto, com o objetivo de verificar se um sistema, aplicação ou parte do software está funcionando corretamente.
Por exemplo, no caso de testes automatizados com Cypress, imagine uma aplicação que possui a funcionalidade de gestão de clientes e três endpoints responsáveis por essa tarefa:
- create (HTTP POST)
- update (HTTP PUT)
- delete (HTTP DELETE)
O primeiro passo é ler as especificações da API — especificamente desses três endpoints e definir um test suite para cada um deles. Em seguida, com base nessas especificações (ou seja, nas regras de funcionamento de cada endpoint), é possível escrever os test suites.
No entanto, há uma diferença importante: os testes serão feitos a partir da interface do usuário (User Interface). Isso significa que, em vez de testar diretamente os endpoints, a automação irá interagir com a interface, que por sua vez fará chamadas a esses endpoints para validar se os requisitos funcionais não estão falhando no código.
Deixando de lado os conceitos teóricos sobre testes e focando na prática, imagine um cenário com mais de dez test suites em um único código, sendo esse código executado em apenas 1 a 2 minutos. Isso representa uma grande vantagem, pois permite integrar esses test suites ao pipeline de CI/CD. Ou seja, sempre que um desenvolvedor fizer um merge request para a branch develop, todos os test cases de todos os test suites serão executados automaticamente.
Caso qualquer test case falhe, não será necessário seguir para a etapa de code review, pois o próprio desenvolvedor saberá que os testes não passaram e, portanto, sua feature ou fix impactou negativamente alguma funcionalidade existente. Assim, será necessário identificar a causa raiz (root cause) da falha antes de prosseguir para a próxima etapa do workflow.
Desenvolvedor full-stack, formado em Ciência da Computação e Redes de Computadores, com certificações internacionais da AWS e IBM. Atuou em projetos de inovação tecnológica no governo de Portugal. Atualmente, trabalha com processamento de dados IoT na telemetria de grandes frotas de veículos em todo o continente europeu, visando otimizar processos, reduzir custos e minimizar impactos ambientais.