Chama o Darth VADER para te ajudar a testar as APIs
O Darth Vader do Star Wars todo mundo já ouviu falar, mas lembrar dele na hora de testar uma API pode ser novidade para você. O uso da Heurística VADER irá te ajudar na hora de focar nos testes das APIs. Ele vai te lembrar alguns dos principais pontos de atenção que precisam ser testados.
Mas você sabe o que é uma Heurística?
O Gabriel Santos escreveu um post todo sobre isso e la ele definiu como:
Heurísticas são processos que ocorrem naturalmente na mente do ser humano. Elas ajudam a solucionar problemas e tomar decisões em condições de incerteza, substituindo a forma complexa de fazer algo, por outra mais simples e ainda assim trazendo resultados satisfatórios.
Neste artigo, Amos Tversky e Daniel Kahneman, estudiosos de psicologia, definem as heurísticas como:
“Princípios que reduzem as tarefas complexas de avaliar probabilidades e prever valores para operações de julgamento mais simples.”
Ou seja, é uma forma de inventar um atalho para que você possa se lembrar de informações importantes. Passamos bastante por essa fase de Heurísticas quando estamos estudando para o vestibular e os professores criam isso para facilitar os estudos.
O VADER
Essa é uma heurística já conhecida no mundo dos testes das APIs. Ela foi criada por Stuart Ashman, a minha intenção hoje é dissecá-la, trazer para você o que cada letrinha do Vader significa e como usar essa heurística para impulsionar seus resultados nos testes.
Começamos pelo V de Verbos
Os Verbos em uma API são nada mais e nada menos que os tipos de Requisições. O importante é antes de tudo saber onde cada um deve ser usado e o porque é usado dentro da sua Regra de Negócio.
POST — Geralmente usado para adicionar, criar novos registros.
PUT — Comumente usado para editar registros criados anteriormente, um ponto de atenção aqui é que o PUT deve e pode ser enviado várias vezes e com os mesmos dados e o estado do servidor não irá ser alterado independente da quantidade de requisições feitas. Diferente do POST que a cada nova requisição um novo registro é adicionado.
DELETE — Esse é simples, vai excluir, mas conheça a sua realidade, a sua Regra de Negócio é definida para excluir o registro? Ou apenas colocar uma tag como “inativa”?
GET — O get é o BUSCAR, podemos buscar todos os registros ou buscar algum específico mandando algum parâmetro, seja ID, nome ou outro qualquer e também depende de conhecer e entender as características do seu produto.
Sim esses verbos são apenas os mais usados e existem alguns outros dentro dos testes de APIs e devemos nos certificar de que todas as requisições estão funcionando da maneira esperada.
Testar esses verbos é executar as requisições, mandar Post, Put, Get e delete. Exercitar todos os verbos e estar atentando a qual é o comportamento esperado de cada um.
A de Autorização
É nesse momento onde devemos nos atentar às variações de autenticação e autorização. A Autenticação é o seu RG, quem você é e a Autorização é onde você pode ir sendo você mesmo.
Alguns cenários que podemos exercitar são: Login com sucesso, recuperando o Token e utilizando esse Token para acessar recursos autorizados. Tentar acessar recursos que o Token não tem autorização. Usar um Token inválido e um Token de outro usuário.
Vamos à alguns exemplos:
Login com sucesso, status code 200 OK e retornando o token que será utilizado nas demais requisições.
Tentando alterar a senha de um usuário, porém passei o token de um 3º usuário. API retornou 401 Unauthorized , pois eu não posso alterar a senha de outro usuário.
Mais um exemplo agora no verbo GET tentando buscar informações do perfil sem passar o Token, API respondeu corretamente mais uma vez, me informando que não estou autorizada a fazer essa requisição.
D de Dados
Aqui o foco deve ser nos dados de cada requisição, fazendo variações que certifiquem que eles estão obedecendo a regra de negócio:
- Tipo: se o dado é uma string, se retorna como string, integer, boolean…
- Formato: pode ser um array ou um campo simples.
- Tamanho dos dados: quantidades máximas, mínimas de cada campo.
- Paginação da lista.
Aqui podemos verificar um erro nos dados retornados pela requisição. Passamos o valor “false” para o atributo ativo, porém a API retornou o mesmo atributo com o valor “true”.
A lista retornada na requisição GET traz o atributo “qtd” com valor igual a 29, foi definido no parâmetro da requisição a quantidade de 10 devem ser retornados por página. O contador de páginas “pagCount” está com o valor 2, então 9 itens não serão exibidos na tela, pois não foram incluídos na paginação
E de Erros
Podemos validar os erros, códigos de erros, se os erros estão sendo tratados ou se alguma combinação de dados está retornando erro interno do servidor (erro 500).
Ter um erro 500 na aplicação não é uma boa prática, pois representa falha na lógica implementada para uma regra de negócio. É essa a hora de investigar o erro e conversar com o desenvolvedor para tratá-lo.
O campo “usuário”, que deve ser de valor único, foi enviado com um valor já existente no banco de dados. A API está retornando um erro 400 (Bad Request) e descrevendo no retorno qual o problema encontrado na requisição. Ok a API não permitiu a quebra da Regra de Negócio porém uma pessoa já cadastrada deveria retornar um 422, pois é relacionado a regra de negócio e não ao contrato que é o 400. Mais uma boa hora para conversar com seu desenvolvedor e tratar essa exceção.
Por algum motivo não foi possível realizar a requisição PUT na rota, porém o erro não tem tratamento, assim o usuário ou o testador não consegue saber o motivo de ter acontecido uma requisição falhada.
R de Responsividade
Responsividade diz respeito a reação da API, como a resposta se comporta. A velocidade de resposta está dentro do esperado? Está estável?
. Cuidado que a responsividade da API é bem diferente em relação a que testamos em aplicações web, onde seria analisado o layout da aplicação com diferentes tamanhos e resoluções de tela.
Quando uma requisição é falha, o tempo para retornar o erro está dentro do esperado?
Estão acontecendo time-outs? Em quais situações? Esporádicos ou constantes?
A API está respondendo satisfatoriamente a um número alto de requisições simultâneas?
As heurísticas são atalhos mentais que quando usados podem nos ajudar a cobrir alguns cenários bem importantes, veja o caso apresentado do Vader conseguimos passar por vários pontos chaves de um básico de uma API.
E aí, curtiu? Já consegue aplicar isso no dia dia a dia?
Referências:
Como sempre os três nomes referências em API para mim, Júlio de Lima, Antonio Montanha
Vinicius Pessoni — Canal Pessonizado
Gabriel Santos — E seu post sobre Heurísticas
E o post do Stuart Ashman
