Durante o processo de desenvolvimento, é importante padronizar os dados de resposta das interfaces. Com especificações relevantes da interface, mesmo que problemas surjam durante iterações subsequentes, desenvolvedores e testadores podem identificar rapidamente a causa do problema.
Para testar se a estrutura de dados retornada por uma interface é padronizada, você pode usar o módulo de documentação da API do Apidog. Primeiro, serão apresentadas estruturas de dados comuns, seguidas de um exemplo para vivenciar o design das estruturas de dados.
Exemplo
1. Problema
Suponha que haja um cenário em que um objeto possui duas propriedades:
tipo: enum
valores: array
Quando o valor do tipo é fixo, o comprimento de valores deve ser 1; quando o valor do tipo é intervalo, o comprimento de valores deve ser 2; quando o valor do tipo é outro, não há limite para o comprimento de valores.
Neste cenário, como podemos limitar o comprimento de valores com base no valor do tipo no Apidog? Para que uma resposta de erro possa ser retornada se a relação entre tipo e valores não puder ser correspondida?
Primeiro, liste todas as possíveis especificações de estrutura de dados com base nos requisitos:
// Tipo A
{
"type": "fixed",
"values": ["1"]
}
// Tipo B
{
"type": "range",
"values": ["1","2"]
}
// Tipo C
{
"type": "other",
"values": ["1","2","89","67"]
}
2. Definir Mock Dados
Para resolver o problema no exemplo de maneira mais conveniente, usamos a função advanced Mock do Apidog para fornecer dados da interface. De acordo com a descrição do problema, precisamos definir 5 tipos diferentes de dados Mock, divididos em 3 verificações bem-sucedidas e 2 verificações falhadas, conforme abaixo:
Quando o valor de type é fixed, o comprimento de values deve ser 1:
Quando o valor de type é range, o comprimento de values deve ser 2:
Quando o valor do tipo é outro, não há limite para o comprimento dos valores:
Quando o valor do tipo é fixo, o comprimento de valores não é 1:
Quando o valor do tipo é intervalo, o comprimento de valores não é 2:
Depois de definir os dados Mock, você pode chamar a interface e verificar se a estrutura de dados na resposta retornada é padronizada.
3. Definir uma Resposta Bem-Sucedida
De acordo com os requisitos mencionados acima, existem três situações correspondentes para os dados de resposta esperados e os dados de resposta retornados, caso contrário, uma resposta de erro será retornada.
3.1 Especificação 1: Resposta bem-sucedida de parâmetro fixo
Defina o tipo como string, adicione um valor de enumeração fixo; defina os valores como tipo array e limite o número de elementos de saída para apenas 1, com elementos do tipo string dentro. Os detalhes são os seguintes:
3.2 Especificação 2: Resposta bem-sucedida de parâmetro de intervalo
Defina o tipo como string, adicione um valor de enumeração de intervalo; defina os valores como tipo array e limite o número máximo e mínimo de elementos para 2, com elementos do tipo string dentro. Os detalhes são os seguintes:
3.3 Especificação 3: Resposta bem-sucedida de outro parâmetro
Defina o tipo como string, adicione um valor de enumeração de outro; defina os valores como tipo array, sem limite para o número máximo e mínimo de elementos, com elementos do tipo string dentro. Os detalhes são os seguintes:
Após definir o exemplo de resposta bem-sucedida, o usuário pode determinar se os dados de interface retornados estão em conformidade com a especificação através do status da resposta ao fazer uma solicitação pela interface.
4. Verificar Dados de Resposta
Os dados de resposta e a especificação de resposta retornada devem corresponder, caso contrário, a verificação falhará. Durante o processo de chamada da interface, é necessário verificar e validar os resultados retornados de forma oportuna para garantir a correção e a integridade dos resultados retornados. Isso pode efetivamente reduzir a probabilidade de falha ou erro na chamada da interface, garantir a consistência e confiabilidade da interface e reduzir os custos de manutenção em um estágio posterior.
4.1 Verificar Especificação 1
Alterar "Verificar Resposta" para "Sucesso Fixo (200)" significa que apenas um valor no array "values" deve ser output para que a afirmação seja bem-sucedida quando o tipo for definido como "fixed".
Insira o valor de 1 no campo de parâmetro e clique no botão "Enviar". Como os dados de resposta pré-definidos estão em conformidade com as especificações esperadas, isso indicará uma afirmação bem-sucedida ✅.
Se o valor de type não for fixed, a estrutura de dados retornada falhou na verificação ❌:
Se o valor de values for null ou mais que 1, a estrutura de dados retornada falhou na verificação ❌:
4.2 Sucesso Intervalo (200)
Alterne "Verificar Resposta" para "Sucesso Intervalo (200)". Isso indica que apenas dois valores são considerados uma afirmação bem-sucedida no array de valores quando o valor do tipo é um intervalo.
Se o valor de tipo não for intervalo, a estrutura de dados retornada falhou na verificação ❌:
Se o valor de values for null ou não houver 2 valores, a verificação da estrutura de dados também falhará ❌:
4.3 Outro Sucesso (200)
Alterar "Verificar Resposta" para "Outro Sucesso (200)" significa que para o valor de type de other, qualquer número de valores no array "values" resultará em uma afirmação bem-sucedida. ✅
Se o valor de tipo não for other, a estrutura de dados retornada falhará na verificação ❌:
Resumo
Além do caso acima, você também pode padronizar outras estruturas de dados no Apidog para verificar se os dados da interface estão padronizados. O Apidog também suporta muitos outros recursos, como importação de interfaces, dados mock e testes automatizados. Clique no link para ler o artigo original e vivenciá-lo por si mesmo!
