Muitos usam o SoapUI para testar a própria API e os aplicativos que acessam a API. Uma ferramenta bastante flexível que permite, por exemplo, exportar um
arquivo API swagger e gerar um serviço Mock com base nele.
Há pouco tempo, em nossa empresa, eu enfrentei um problema semelhante, mas com condições não triviais. Dados iniciais: é necessário testar um aplicativo de servidor que recebe uma tarefa como entrada; durante a execução, refere-se à API; cada solicitação subsequente depende da resposta da API. A lógica está incorporada no aplicativo. Ou seja, um tipo de caixa preta em que você precisa testar muitas saídas do script, quando houver apenas uma entrada para o script.
A seguir, proponho um exemplo de solução que permite que ela seja facilmente integrada à infraestrutura de regressão, além de ter uma margem para escalonamento, no caso de aumentar a cobertura da variedade de cenários e de sua complexidade.
Primeiro, crie um serviço Mock no SoapUI. Isso é feito em alguns cliques:
Agora, vamos criar stubs para consultas. Como existe apenas uma entrada no script na tarefa, temos opções:
- use o identificador do script e passe-o em cada solicitação e, em cada stub, determine a resposta dependendo desse identificador;
- especifique previamente uma lista de respostas para cada esboço e armazene-as em variáveis globais antes de executar o teste.
A primeira opção pode ser usada quando for necessário receber uma resposta do stub para várias solicitações ao mesmo tempo. A implementação requer que o aplicativo cliente possa transmitir um identificador específico em cada solicitação de API. No nosso caso, isso era praticamente impossível, e o teste simultâneo de vários cenários não era necessário, portanto a segunda opção foi escolhida.
Portanto, para atribuir uma lista de respostas stub, executamos a seguinte consulta antes de executar o teste:
Post: http:
No serviço Mock, adicionamos o processamento de solicitação "SetScenario". Possui apenas duas respostas: "200_OK" se a solicitação recebida foi processada corretamente e "400_BadRequest" se a solicitação foi feita incorretamente:
No script, distribuímos os valores de resposta para stubs globais para cada stub:
def reqBody = mockRequest.getRequestContent() // def reqBodyParams = [:] reqBody.tokenize("&").each // , { param-> def keyAndValue = param.split("=") reqBodyParams[keyAndValue[0]]=keyAndValue[1] } if (reqBodyParams.containsKey('ScenarioId')) // ID ( ); { // , , “?:” – : context.mockService.setPropertyValue("ScenarioId", reqBodyParams["ScenarioId"] ?: "0") context.mockService.setPropertyValue("Authentication", reqBodyParams["Authentication"] ?: "200_OK") context.mockService.setPropertyValue("AutoSystemHome", reqBodyParams["AutoSystemHome"] ?: "200_OK") // … return "200_OK" } else { return "400_BadRequest" }
As variáveis atribuídas podem ser vistas na janela de configurações do serviço:
Assim, descrevemos toda a lógica do serviço Mock nesse método e, nos stubs dos métodos da API, basta escrever um script que leia o valor da resposta da variável global:
Authentication = context.mockService.getPropertyValue("Authentication") return "${Authentication}"
AutoSystemHome = context.mockService.getPropertyValue("AutoSystemHome") return "${AutoSystemHome}"
Se você precisar adicionar scripts de tempo limite, respostas atrasadas e adicione a variável delay, por exemplo:
Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Delay=600&Authentication=200_OK &AutoSystemHome=400_TokenIsMissing…
E no script stub, adicionamos:
… Authentication = context.mockService.getPropertyValue("Authentication") Delay = context.mockService.getPropertyValue("Delay").toInteger() sleep(Delay) return "${Authentication}"
Se for necessário apoiar a solicitação repetida, transferimos a lista de respostas:
Body: Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200_OK
E no script de processamento, adicione tokenize e exclua a resposta já enviada, se não for a última:
def Authentication = [] Authentication = context.mockService.getPropertyValue("Authentication").tokenize("%3B") if (Authentication.size() > 1) { Authentication.remove(0) Authentication = Authentication.join("%3B") context.mockService.setPropertyValue("Authentication", Authentication) }
Como resultado, obtivemos um serviço Mock simples, fácil de mover entre bancos de teste e ambientes, porque o arquivo do projeto é um arquivo xml. O serviço inicia imediatamente após a importação, sem configurações adicionais (exceto para alterar o endereço e a porta do servidor, é claro). No momento, ele nos ajuda a testar o aplicativo, independentemente da estabilidade do servidor IPA e dos possíveis períodos de inacessibilidade.
O que pretendemos adicionar: integre esta solução para testar aplicativos antes e durante o desenvolvimento da própria API. Por exemplo, quando sua descrição já está pronta na forma de um arquivo arrogante, mas o servidor está em processo de configuração. Os ciclos de desenvolvimento de API e aplicativos clientes nem sempre coincidem. Nesse momento, é útil testar alguma coisa o aplicativo cliente em desenvolvimento, e o serviço Mock pode ajudar bastante.
UPD: caso você tenha perguntas e comentários úteis.