Boas práticas para testes automatizados de API
Um guia para criação e manutenção de testes automatizados de API
Adicionar testes automatizados de API para projetos com arquitetura orientada a microserviços agregam muito valor à qualidade de entrega ao cliente, alertar problemas por meio de testes periódicos, além de trazer mais confiança para a equipe em relação à mudanças através de testes de regressão rápidos e confiáveis.
A elaboração com qualidade de um projeto de teste de software requer considerações antes e depois da criação dos testes em si. A imagem a seguir exibe sugestões de etapas que podem ser adotadas de acordo com o tempo disponível, considerando que ao executar apenas partes do processo poderá comprometer a qualidade de todo projeto.
O fluxo inicia com o entendimento do projeto, onde é repassado para a equipe sua visão de negócio e técnica. Isso serve de base para escolher as tecnologias (linguagem de programação, arquitetura REST ou SOAP) ferramentas (IDE, compilação com Maven, Gradle, etc.) que serão utilizadas para criação dos testes automatizados de API. É aconselhável considerar também as definições da equipe de desenvolvimento nesses tópicos, para maior padronização e compartilhamento de conhecimento entre o time.
É interessante realizar uma verificação sobre a necessidade de reservar um tempo para estudar o que for necessário relativo às tecnologias e ferramentas escolhidas.
Idealmente a equipe de testes contará com estruturas como Swagger para servir como principal referência de documentações técnicas das APIs. Caso esteja disponível é possível avaliar se os métodos HTTP estão seguindo os padrões, assim como entradas e saídas de dados.
Outra fonte de documentação técnica é o código fonte do projeto, onde as mesmas informações estão disponíveis no formato de linguagem de programação. Podemos aplicar a mesma avaliação de padrões e dados mencionadas anteriormente.
Como último recurso a documentação de negócio do projeto será o guia para antecipar cenários de teste, enquanto a indispensável documentação técnica não é disponibilizada.
Para evitar a validação dos mesmos cenários de teste, devemos avaliar a cobertura preexistente dos testes criados pelos desenvolvedores, compostos geralmente por testes unitários ou integrados.
Seguindo o conceito da pirâmide de testes, ao definir a estratégia estabelecemos quais testes serão criados, podendo ser de contrato, unitário, integrado, e suas proporções, ou seja, a quantidade adequada de cada tipo de teste.
Em posse da documentação das APIs, com tecnologias, ferramentas e estratégias definidas podemos começar a planejar cenários de teste, elencando apenas seus títulos. Para testá-los, antes de partir para o código fonte, podemos usar uma ferramenta auxiliar como o Postman para executar os testes.
Quando todos testes estiverem OK, podemos transcrevê-los para a linguagem de programação escolhida.
No momento que o ciclo de desenvolvimento estiver finalizado, é válido realizar uma verificação se os cenários criados têm uma boa cobertura, se houve mudança no escopo será necessário replanejar os cenários, acrescentando os que faltam ou removendo o que não faz mais parte do projeto. Ferramentas de cobertura de código, como o Sonar, podem auxiliar nesta análise final de codificação.
Para exibir os resultados em um formato mais amigável e acessível para todos da equipe, incluindo a área de negócio e o cliente, podemos utilizar uma ferramenta de Report, como o Allure. Será necessário incluirmos algumas tags nos cenários de teste para que informações adicionais sejam incluídas no Report.
Antes da finalização do fluxo, a criação de métrica para automação é aconselhada por medir o quanto os cenários de teste automatizados estão contribuindo com a qualidade do projeto.
Por fim, a inclusão dos testes automatizados no processo de Integração Contínua, através de ferramentas como Jenkins, fará com que todo o processo de desenvolvimento e manutenção sejam validados pela automação de testes.
