Porque é necessário o testing em APIS?

Para podermos falar de testing em API, primeiro é preciso saber o que é uma API. Uma API, ou Interface de Programação de Aplicações, é um conjunto de definições e protocolos que se utilizam para desenvolver e integrar o software das aplicações, permitindo a comunicação entre diferentes aplicações de software através de um conjunto de regras.

As APIs surgiram nos primórdios da informática, muito antes do computador pessoal. Nessa altura, uma API era utilizada normalmente como biblioteca para os sistemas operativos. Estavam quase sempre habilitadas localmente nos sistemas em que operavam, ainda que por vezes passassem mensagem entre os computadores centrais. Após quase 30 anos, as APIs expandiram-se para além dos seus ambientes locais. No início do ano 2000, já era uma tecnologia importante para a integração remota de dados.

Para que serve uma API?

Uma API facilita o nosso trabalho no momento de desenvolver um software e desta forma é possível economizar tempo e dinheiro. Por exemplo, se criamos uma página na qual podemos consultar o clima atual, em vez de ter que fazer todo o desenvolvimento para obter informação climática precisa, podemos fazer uso das APIs da meteomatics, que, com uma simples consulta nas suas interfaces, devolverá a informação que necessitamos relativas ao clima atual. Desta forma, muitas vezes, evita ter de se despender de tempo e dinheiro em desenvolver algo que já existe e está à disposição de outros programadores.

Testing em APIS

O testing em API é frequentemente negligenciado quando se fala de automatização, mas na realidade a sua relação custo/beneficio é muito mais elevada que a automatização de front-end.

Com as vantagens na utilização de APIs, surgem necessidades como testar requisitos não funcionais, por exemplo, os seus tempos de resposta ou a capacidade máxima de pedidos por segundo suportados, ou requisitos funcionais como validar que o conteúdo da resposta é o esperado.

Para resolver estas situações, existem diferentes tipos de testing que podem ser aplicados a APIs como, por exemplo:

• Testing automatizado
• Testing de desempenho

Os testings automatizados são responsáveis por verificar ou validar principalmente a resposta do pedido, se a resposta é esperada e se os tipos de dados a receber pela Interface são corretos.

Por outro lado, o testing de desempenho preocupa-se principalmente em obter métricas do sistema e testar a velocidade de resposta com base na simulação de múltiplos pedidos simultâneos e, desta forma, ver qual o nível de carga que a Interface suporta.

Para testar um API, a primeira coisa a fazer é conhecer os diferentes códigos de status do pedido feito:

• 1xx Status Code => Informação
• 2xx Status Code => Pedido bem-sucedido
• 3xx Status Code => Redirecionamento
• 4xx Status Code => Erro por parte do Utilizador
• 5xx Status Code => Erro por parte do Servidor

Dentro de cada categoria existem diferentes mensagens de informação dependendo do valor de xx, podendo consultar-se esta informação em restfulapi. Para poder realizar testes em APIs existem diferentes ferramentas que nos permitem desempenhar esta função, sendo uma das mais utilizadas o Postman.

Apesar de, para uso pessoal, podermos utilizar a versão gratuita, Postman também tem diferentes licenças pagas com melhores funcionalidades, tais como poder recuperar coleções eliminadas ou ter colaborações entre equipas de 4 ou mais membros para trabalhar nas mesmas coleções.

Este programa permite realizar tantos pedidos quantos necessitar, e também pode agrupar os pedidos em diferentes coleções (pastas) de acordo com a API que pretende testar.

Com Postman, pode-se também efetuar a execução automática de uma coleção, lançando assim os diferentes pedidos que tenham sido armazenados na coleção.

Além disso, podem ser gerados diferentes testes dentro de cada pedido dando uso à biblioteca interna da pm para verificar, por exemplo, o tipo de dados esperados, valor do Status Code, valor de um campo específico na resposta, tipos de cabeçalho, etc.

Existe um runner através da linha de comandos que permite executar as coleções onde se encontram os pedidos API guardados

Para gerar scripts, é possível consultar a informação oficial do Postman, onde encontrarás documentado tudo sobre como trabalhar na secção Test dentro de cada pedido ou coleção. Existem outras ferramentas que nos permitem testar em APIs como a SoapUI, apesar de a mais utilizada é o Postman por oferecer as seguintes vantagens:

• Admite a colaboração entre membros de equipa.
• Tem uma interface muito mais intuitiva e atrativa, o que torna a sua utilização mais simples.
• Possui API Network, que é um repositório de APIs que permite o acesso direto às mesmas, bem como a possibilidade de documentar e estudar a sua utilização. Também é possível publicar APIs neste serviço de forma privada, apenas acessíveis por uma determinada organização.
• O Postman é mais amplamente utilizado, por isso há mais documentação.
• O custo das licenças é mais barato comparado com outras ferramentas.

Além disso, existe um runner através da linha de comandos que permite executar as coleções onde se encontram os pedidos API guardados. Este runner chama-se Newman. Este complemento é bastante utilizado, especialmente quando se trata de Integração Contínua ou CI (continuous integration). Permite que, através de ferramentas como o Jenkins, se possam executar as coleções do Postman de forma simples, e também, na documentação oficial Postman, é possível encontrar uma secção sobre como integrar Newman com ferramentas de CI.

É realmente necessário o testing em apis?

Com o tempo, a utilização de APIs tornou-se cada vez mais comum no desenvolvimento de produtos e serviços. Muitas aplicações baseiam-se na utilização destas interfaces para recolher informação de diferentes fontes e, assim, ter um sistema centralizado no qual se pode consultar informação; por exemplo, quando queremos consultar diferentes tarifas de hotéis, seguros, produtos, etc.

Este tipo de páginas que oferecem comparações entre diferentes empresas com o mesmo produto acabam por fazer uso destas APIs para recolher informação de forma rápida e eficaz. Portanto, é essencial que estas APIs funcionem corretamente: sem erros e com um tempo de resposta adequado.

Arquitetura API-First

A API de uma aplicação web é muitas vezes considerada um elemento secundário, o que não é necessariamente incorreto.

Contudo, se se está a pensar num serviço como um sistema complexo, no qual existem múltiplos pontos de contacto com os utilizadores, tais como web, telemóveis, escritórios de apoio ao cliente, etc., então é conveniente pensar e desenhar a arquitetura da sua plataforma centrando-se nas APIs que permitem o seu funcionamento, e é aí que entra a arquitetura API-First.

API-First é uma arquitetura que trata o utilizador da API como o utilizador principal da aplicação. Isto significa que a API não é vista como uma alternativa no paradigma MVC, mas sim vista com a prioridade mais elevada.

Na API-First a arquitetura impõe uma API completa, responsiva e bem documentada. A utilização desta arquitetura torna mais fácil ver a necessidade e a importância de testar as APIs, uma vez que, no final se assegura o funcionamento correto do núcleo da aplicação.

Num outro artigo discutiremos em detalhe a abordagem correta para testar em aplicações com a arquitetura API-First.