Estratégias de testes de APIs

Este é o primeiro de uma série de textos que iremos publicar relacionados às ferramentas utilizadas para realizar testes de serviços. Em nossos posts anteriores, já falamos sobre estratégias para testes de software, automação de testes funcionais web, e agora falarei sobre uma opção de abordagem para testes de serviço. Se você não tem conhecimento sobre o conceito de testes de APIs e suas variações, é interessante fazer uma leitura complementar – uma opção é este texto sobre um dos encontros da nossa Comunidade Prática de Qualidade.

Pirâmide de Testes, por Mike Cohn

Na SoftDesign, acreditamos que existem várias estratégias de testes passíveis de aplicação em um projeto. A escolha de uma delas depende do contexto, das skills dos profissionais que integram o time, da tecnologia utilizada, entre outros. Entretanto, essa regra não é válida quando falamos de esforço de testes para as camadas de uma aplicação. Mike Cohn, no livro Succeeding with Agile, apresenta o conceito de pirâmide de testes na qual uma suíte é constituída de três camadas de testes: Unidade, Serviço e Interface.

Ainda que este texto não seja sobre testes unitários, é importante deixar claro que indicamos fortemente o investimento de tempo de desenvolvimento nessa camada, principalmente se a aplicação está em fase inicial de construção. Caso você esteja trabalhando em um sistema legado, simplesmente comece de alguma forma, pois o aumento de segurança no código será observado em um curto espaço de tempo.

Pipeline, por Elias Nogueira

No Scrum Rio 2019, o palestrante Elias Nogueira falou sobre como efetivar o máximo de cobertura nos testes de APIs, sugerindo um raciocínio em testes similar à divisão de Pipeline, ou seja:

• Garantir, primeiramente, que os endpoints que serão testados estão respondendo, caso contrário não seria possível evoluir os testes;
• Depois, validar se os atributos do JSON estão ou seguem de acordo com o estipulado, visto que qualquer alteração de nome dos atributos deve acontecer por causa de algum refactor de código ou porque houve alguma alteração na regra de negócio que precisa ser validada – e as aplicações que estão consumindo o serviço precisam ser ajustadas.
• Em seguida, efetivar o ciclo funcional com o objetivo de realizar validações de regras de negócio, observando os métodos da requisição, os status e dados que estão trafegando na requisição e na resposta;
• E, por fim, prosseguir com os testes de aceitação: se o serviço tem integração com um front-end, entendemos que os testes necessitam da integração da interface para serem aceitos; já no contexto em que a API se conecta outra API, o aceite pode ser a validação do contrato entre os serviços

Validação de Serviços Rest

Este primeiro texto mostra como realizar testes de APIs (serviço) com Postman, mas os exemplos que daremos a seguir vão servir para qualquer outra ferramenta de validação de serviços Rest, como o Rest-Assured TestMace, Restlet, SoapUI ou JMeter, basta adaptar ao contexto. Utilizamos o Postman pois ele facilita a integração no pipeline, sendo necessário apenas exportar o JSON e utilizar o Newman.

Agora vamos falar sobre como aplicá-lo na rotina do trabalho de forma genérica, e ao longo dos próximos posts iremos aprofundar o tema.

Variáveis globais

Variáveis globais auxiliam muito na manutenção dos testes. Por exemplo, você pode utilizá-las para alterar a URL do serviço de acordo com o ambiente em um pipeline de CI ou CD, para versionar a API, para organizar os headers e tokens de autenticação, entre outros.

Como pode ser observado na imagem acima, criei duas variáveis globais, a primeira “BASE_URL” para indicar qual o link do serviço, e a segunda “jwt_token” para colocar a token do serviço. Mantenho o valor inicial e o valor atual em branco, pois o valor será inserido quando os testes forem executados. Também utilizamos as variáveis globais para centralizar as rotas dos serviços e poder reutilizá-las nos scripts.

Deste modo a aplicação fica assim:

Como organizar a suíte de testes

É comum ver coleções sem uma estrutura lógica de validação e de evolução da aplicação que está sendo testada. Como pode ser observado na imagem a seguir, o que cada requisição vai validar não está legível. Com o passar das iterações, é natural que fique cada vez mais complicado gerenciar e dar manutenção nos testes.

Para organizar a suíte de testes, sugerimos a separação das pastas coleção por rotas ou caminhos, pois isso facilita a visualização dos testes e auxilia na organização em cada iteração, além de permitir rodar pre-request que auxiliam a gerar dados para os testes.

Essas duas dicas são básicas e iniciais, mas são a base para todas as outras dicas que iremos dar ao longo dos próximos posts. Assim que você colocá-las em prática, já poderá observar que seus testes de APIs terão uma fluidez maior e menor manutenção, resultando em economia de tempo, visto que você estará eliminando pequenos desperdícios.

Referências

Dicas de Programação; Simple Programmer; Inflectra; Quora; Elias Nogueira; Get Postman (1); Get Postman (2); Mountain Go At Software; Martin Fowler.