POISED Testing: o que é e como utilizar?
POISED Testing: o que é e como utilizar?
Já ouviu falar sobre modelos heurísticos? Resumidamente, são métodos que nos ajudam a entender e lembrar de algo rapidamente, como atalhos mentais. Por isso, no caso do tema que vamos falar hoje: POISED Testing, esses modelos irão ajudar muito!
O método heurístico de representatividade é utilizado como base para criar e pensar nossos testes de API.
O que é POISED?
Primeiramente, vamos dar uma olhada no que isso significa e como pode nos ajudar de fato! O significado das siglas de POISED Testing é:
- P – Parameters (Parâmetros);
- O – Outputs (Saídas);
- I – Interoperability (Interoperabilidade);
- S – Security (Segurança);
- E – Errors (Erros);
- D – Data (Dados).
O que cada uma dessas etapas significa?
Bom, visto que agora sabemos o que cada uma das letras de POISED Testing representa, vamos entender melhor a função de cada uma.
Parameters (Parâmetros)
Esta é a etapa em que você cria seus testes baseados nos parâmetros que a API a ser testada pode enviar. Isso pode funcionar tanto nos headers, parâmetros de URL e parâmetros no envio de dados, como o body de uma request com método POST.
Por exemplo:
- Uma URL aceita ser enviado um header com um tipo de “content-type” x ,y,z e você envia um tipo não aceito;
- Uma URL precisa de um header específico para saber para qual parte da aplicação enviar e você não passa nesse header obrigatório;
- Um body de um request POST, para fazer um login num portal, precisa de campos obrigatórios e tipados por exemplo:
{
“email”: “” ,
"password": 12345678
}
Aqui você deveria ter passado um e-mail válido e passou uma string vazia. Além disso, na senha, deveria ter sido uma string e você passou um numérico qualquer.
Podemos ficar horas vendo tipos de parâmetros. Entretanto, com esses básicos já dá para entender e ir mais além do que seria o P desse modelo!
Outputs (Saídas)
Essa etapa será onde você criará seus testes baseados nas respostas das requests, validará se são coerentes, se estão corretas de acordo com o tipo de request e o status code recebido (response body x status code), logs feitos no console ou no servidor.
Por exemplo:
- Você envia uma requisição do método DELETE e recebeu status code 200 ou 204, mas no corpo da resposta recebeu “criado”;
- Você envia uma requisição do método POST e recebe um status code 200 e com o corpo da resposta vazio;
- Validar se os logs apresentados no console ou servidor são coerentes ou se possui o mínimo de informação relacionada.
Em tese, o Output é onde você cria seus testes para validar a coerência das respostas X o que foi requisitado.
Interoperability (Interoperabilidade)
Aqui é uma etapa muito importante, em que você cria testes para validar e checar a Interoperabilidade da comunicação das APIs, onde você cria testes de contrato, checa a idempotência da API, entre outros.
Além disso, nesta etapa, também pode ser pensado e criado testes de performance para entender qual a performance da sua API, quando muito exigida ou chamada por outros serviços ou outras APIs.
Por exemplo:
- Criar teste de contrato para, sempre que uma API precise, chamar os requisitos básicos e predefinidos como corretos, sendo atendidos e validados em seu comportamento. Por exemplo, o que uma API espera de parâmetros no body? Quais os tipos desses parâmetros? Quais as saídas? É importante não confundir com o teste de schema, onde é validado somente os tipos do schema.
- Validar a idempotência da API. Verificar se, mesmo ela sendo chamada n* x vezes por outra API ou outras, aquele comportamento esperado continua sendo o mesmo sempre.
- Criar testes de performance para latência e/ou saber o tempo de resposta de cada request depois de ter sido carregada com muitas requests.
Security (Segurança)
Uma das partes mais importantes do nosso modelo é criar testes e pensar estratégias de teste para cobrir possíveis cenários ou gaps de segurança na API. Por exemplo:
- Validar que, somente com informações corretas, você consegue chamar com sucesso os endpoints que precisam de autorização e autenticação, como tokens, cookies ou até mesmo senhas;
- Autenticar tempo de expiração das credenciais;
- Validar se é possível, por exemplo, ao invés de mandar a autenticação correta, você consegue mandar algum script de JavaScript no campo;
- Confirmar possíveis mensagens de respostas que contenham mais informação que o necessário ou logs que contenham informações internas, como logar o erro do banco de dados diretamente.
Errors (Erros)
Nesta etapa, podemos pensar sobre como validar as mensagens de erro (já vimos um pouco sobre isso nos tópicos Outputs e Security). Por exemplo:
- Pensar se estão de acordo com o contexto, requisição, ambiente e etc.;
- Verificar as mensagens de erro X o status code da resposta;
- Verificar se nos passam o real problema que aconteceu (pensando sempre na segurança, como dito acima).
Data (Dados)
Nesta fase, pensamos como validar os dados. Por exemplo:
- Validar as estruturas dos dados das requests, no body ou parâmetros;
- Validar os dados quando executamos alguma requisição que altere dados. Por exemplo, quando fazemos um delete, update ou created. Os dados foram corretamente atualizados ou deletados? Após as alterações, a estrutura continua a mesma? E por aí vai…
Pensando nisso, é importante lembrar:
- Precisamos sempre ter contato e conhecimento do código base para poder criar os testes com mais precisão e sempre com base na documentação;
- Além disso, é preciso checar também os testes unitários, para não cairmos no problema testes duplicados em camadas diferentes.
Conclusão
Passamos por um overview sobre o POISED Testing, para nos dar ideias e nos guiar quando pensarmos sobre criação de testes de API. Como falamos acima, este é um modelo heurístico que usamos para apoio.
Existem alguns outros modelos interessantes, segue aqui uma lista para você checar, se tiver interesse!
- VADER
- BINMEN
Autor: Francisco Antônio Navarro Moral.
Leia também: