Mitigando inconsistências em APIs REST através de testes de retrocompatibilidade
Um teste não funcional que pode prevenir inconsistências severas na aplicação
As normas ISO da família 25000 tem o objetivo de criar um framework para avaliar a qualidade de um software. A ISO 25010 detalha quais características de um software devem ser levadas em consideração para que este seja considerado um produto de qualidade, levando em conta os anseios dos stakeholders (funcionalidade, performance, segurança, etc).
Além disso, a ISO 25010 define oito características primordiais que qualquer software deveria ter, para melhor atender as necessidades dos clientes e gerar valor. São elas:
- Adequação Funcional;
- Eficiência de desempenho;
- Compatibilidade;
- Usabilidade;
- Confiabilidade
- Segurança;
- Manutenção;
- Portabilidade.
Neste artigo, iremos focar em testes voltados à Compatibilidade.
Testes de compatibilidade
Os testes de compatibilidade avaliam se a aplicação é capaz de ser executada em diferentes tipos de hardware, software, rede, ambiente e qualquer tipo de dispositivo, avaliando tanto questões de interoperabilidade quanto de coexistência deste sistema em relação à plataforma em que estão sendo executados.
Existem diversos tipos de testes de compatibilidade e um deles em especial, os testes voltados para a versão da aplicação são divididos em backward compatibility testing (retrocompatibilidade) e forward compatibility testing (compatibilidade futura).
Os testes de retrocompatibilidade verificam se a versão atual do software é compatível com versões anteriores dele próprio ou de outras aplicações que o consome. Já o segundo, verifica se a versão atual do sistema será compatível com versões futuras. Este último é mais complexo de se pensar/fazer.
Por exemplo, as versões atuais do Microsoft Office devem ser compatíveis com suas versões anteriores. Por exemplo, Microsoft Office 2016 ser capaz de abrir e carregar sem problemas arquivos criados na versão 2013.
Já nos testes de compatibilidade futura, a versão atual do office deve ser compatível com protótipos de versões do office que ainda estão sendo desenvolvidas.
Tá, mais o que isso tem a ver com testes de API?
Testando a retrocompatibilidade em APIs REST
Existem várias formas de testar retrocompatibilidade em APIs REST. Rajesh Bhojwani, em seu artigo, definiu alguns pontos que podemos observar neste tipo de situação:
- Criação de testes de unidade voltados especificamente para testes de retrocompatibilidade;
- Testes automatizados de contratos, adicionados a esteira de CI/CD, que poderiam alertar caso houvessem falhas relacionadas à retrocompatibilidade dos contratos;
- Versionamento da URI da API REST;
- Utilizando o Swagger-Diff, solução também preferida por ele.
Swagger-Diff
O Swagger-Diff é uma ferramenta que detecta a diferença entre duas especificações (swagger) distintas de API, como por exemplo, uma versão atual com uma versão mais antiga.
Ele provê funcionalidades que, além de detectar estas diferenças, facilitam a sua integração em uma esteira CI/CD, sendo executado como um teste automatizado, além da possibilidade de customizar os tipos de alertas que serão enviados, caso haja alguma falha identificada.
Estas falhas são classificadas em dois grupos:
- Smooth changes, pequenas alterações, tais como adição de um parâmetro opcional no corpo da requisição;
- Breaking changes, grandes alterações, tais como tornar um atributo opcional obrigatório ou a remoção de um endpoint da API.
O resultado apresentado, após a execução da ferramenta, é demonstrado a seguir:
O Swagger-Diff dá a possibilidade de compararmos duas URLs de swagger ou dois arquivos JSON, contendo informações da API. No exemplo mostrado, foram utilizados arquivos JSON salvos localmente no computador.
Após a execução do swagger-diff, podemos avaliar os seguintes pontos:
- Missing endpoints: três endpoints foram excluídos da API, o que seria classificado como uma grande alteração.
- Incompatible request params: alguns parâmetros de query da requisição get/pets foram removidos;
- Incompatible response attributes: a resposta default para a requisição get/pets foi removida da API.
Instalando e utilizando o Swagger-Diff
No exemplo demonstrado anteriormente, utilizou-se a versão em Node do swagger-diff, além desta ele também foi desenvolvido em várias outras linguagens como Ruby e Java.
Antes de utilizar a aplicação, é necessário instalar o Node.js. Após efetuar a instalação, basta utilizar o comando a seguir:
npm install swagger-diff
Simples, não é?
Após a instalação, basta executar o comando da seguinte forma:
- swagger-diff <arquivo-swagger-antigo> <arquivo-swagger-novo>
No exemplo demonstrado anteriormente, foram utilizados arquivos locais para realizar a validação, mas lembre-se de que também pode-se utilizar URLs para fazer a comparação entre swaggers.
O Swagger-Diff é uma solução simples, fácil de implementar e de execução rápida que pode ajudar bastante na comparação de duas especificações de API, prevenindo que qualquer mudança não planejada/conhecida escorregue acidentalmente para o ambiente de produção.
Além disso, o swagger-diff pode ser executado automaticamente em esteiras, sendo também um tipo de teste automatizado.
Testar a retrocompatibilidade da API garante que qualquer nova implementação ou alteração que fizemos na aplicação não irá impactar negativamente os clientes ou serviços que as consomem, trazendo mais confiabilidade nos deploys deste tipo de sistema.
Vocês já ouviram falar sobre testes de retrocompatibilidade, já utilizaram alguma técnica voltada para este assunto ou conhecem o swagger-diff? Vamos discutir este tema nos comentários, adoraria saber a opinião de vocês! #hugs
