wiremock tutorial introduction wiremock
Este tutorial em vídeo introdutório explicará os recursos do Wiremock e como executar o Wiremock como um servidor independente e como parte dos testes JUnit:
Neste tutorial, abordaremos os conceitos básicos e os detalhes da ferramenta Wiremock. Ele pode ser usado como um servidor HTTP independente, bem como nos testes JUnit de acordo com os requisitos.
Esta é uma ferramenta muito usada, pois é de código aberto e tem uma grande comunidade de colaboradores. Ele vem na categoria de ferramentas de virtualização de serviço.
O que você aprenderá:
O que é Wiremock?
Em termos simples, o Wiremock é uma configuração de simulação para testes de integração. É simplesmente um servidor fictício altamente configurável para retornar uma resposta esperada para uma determinada solicitação.
É amplamente usado durante o desenvolvimento e, mais importante, durante o teste de integração, enquanto um sistema ou serviço se comunica com um ou várias dependências / serviços internos ou externos.
Vamos tentar entender mais sobre os testes de integração em geral e saber como a Wiremock pode ajudar a superar esses desafios e tornar nossas vidas mais fáceis.
Geralmente, quando vem a palavra integração, o que nos impressiona é uma integração de ponta a ponta entre 2 sistemas de comunicação. Agora, vamos olhar para isso da perspectiva de um aplicativo em teste que usa algum serviço externo para fazer o trabalho.
Por exemplo, vamos supor que estejamos construindo um aplicativo para viagens online ou sistema de emissão de bilhetes e temos um módulo para verificação de status do PNR, que atinge uma API externa fornecida pela Indian Railways.
Agora, como podemos testar a integração do nosso aplicativo com as APIs externas?
Existem 2 maneiras de fazer isso:
- Primeiro, é a abordagem de teste de unidade, em que criamos um esboço da interface fornecida (ou criada internamente) para que nosso sistema teste / valide a resposta esboçada ou falsa antes mesmo de acessar a API externa. Isso nada mais é do que um teste de unidade tentando simular uma dependência externa.
- Segundo está testando com algum ambiente de teste (ou o ambiente de produção real) das dependências externas. No entanto, existem vários desafios com essa abordagem, conforme mencionado abaixo:
- Os sistemas API externos nem sempre estão disponíveis. ou seja, somos fortemente dependentes ou dependentes de sistemas externos e qualquer tempo de inatividade afetará nossos testes e, indiretamente, o processo de desenvolvimento / lançamento.
- Em segundo lugar, APIs externas podem ou não ter um ambiente de teste. Por exemplo, uma API de verificação de status do PNR sempre pode exigir números PNR reais para buscar e retornar respostas.
- Muitas vezes, há custos envolvidos na obtenção de uma API. Por exemplo, suponha que a API de verificação de PNR cobra Rs 100 para cada 1000 solicitações. Como os testes de integração geralmente são executados durante cada regressão (e na maioria das vezes com cada confirmação), pode não ser uma solução econômica atingir uma API que nos custa até mesmo para fins de teste.
- Uma API externa não pode ser configurada para retornar a resposta desejada. Mesmo se possível, você terá que criar muitos dados de teste para garantir diferentes respostas para diferentes entradas de solicitação.
Por exemplo, você deseja testar cenários de erro como uma API está retornando diferentes códigos de status para diferentes tipos de dados. Agora, como a resposta não está sob nosso controle, precisaremos criar vários conjuntos de dados para validar diferentes cenários ou resultados possíveis.
Vamos entender esses conceitos com a ajuda do diagrama abaixo.
Aqui, estamos comparando as duas abordagens de teste de integração, ou seja, sem um servidor simulado usando uma implementação real da dependência externa e usando o servidor simulado (Wiremock) que simula respostas às solicitações recebidas para a dependência.
No último caso, ele reduz muito a dependência e a confiança na implementação real da dependência e oferece muitos recursos de configuração sem comprometer a qualidade e os cronogramas de entrega.
Como a Wiremock responde a uma determinada solicitação?
Como sabemos, o Wiremock é um servidor Mock programático, a maneira como ele responde a uma determinada solicitação é armazenando todos os mapeamentos relevantes (ou respostas simuladas) em uma pasta chamada 'mapeamentos'
Há um componente de correspondência do Wiremock que faz a correspondência das solicitações recebidas com os mapeamentos armazenados e, se uma correspondência bem-sucedida for retornada, a primeira correspondência será retornada como a resposta para a solicitação dada.
Caso você esteja usando a versão autônoma do Wiremock, depois de executar o servidor Wiremock, verá a pasta de mapeamentos que será criada no diretório de instalação / jar do Wiremock.
Tutorial em vídeo: introdução à ferramenta Wiremock
perguntas da entrevista de serviços da web em java
Como usar o Wiremock?
Agora vamos ver como podemos usar essa ferramenta com nossos testes de integração.
Ele pode ser usado das seguintes maneiras.
Um servidor Wiremock independente
Como um servidor autônomo, você pode apenas criar um aplicativo Java simples com dependência Maven / Gradle para Wiremock e mantê-lo como um processo em execução.
Esta é uma boa alternativa quando você deseja hospedar seu servidor autônomo em alguma máquina e usá-lo como um único servidor de simulação para todo o projeto ou equipe. No modo autônomo, esta ferramenta também pode ser executada, baixando o jar autônomo disponível aqui e simplesmente execute a jarra.
Por exemplo, Suponha que você deseja implantar sua instância autônoma Wiremock em algum servidor na nuvem ou em um servidor local, então você pode simplesmente executar este jar e usar o IP do sistema para usá-lo como um serviço hospedado.
Vamos ver alguns etapas para executar isso no modo autônomo (e configurar coisas diferentes como portas, mapeamento de pastas, etc)
# 1) Execute o jar do Wiremock a partir do terminal (ou prompt de comando para usuários do Windows) como qualquer outro arquivo JAR (do diretório de instalação do jar do Wiremock).
java -jar wiremock-standalone-2.25.1.jar
#dois) Por padrão, o Wiremock é executado no host local: 8080 (se a porta estiver livre para uso, o comando acima iniciará o servidor Wiremock em um modo autônomo) e você verá a saída conforme abaixo.
# 3) Agora, uma vez que o servidor é iniciado, você pode visitar qualquer URL em localhost: 8080
Por exemplo, http: // localhost: 8080 / get / user / 1 - Como atualmente não há simulações sendo definidas, você receberá uma resposta conforme mostrado abaixo.
# 4) Agora vamos tentar configurar um esboço / simulação simples para este URL e tentar acessar o URL novamente. Em seguida, validaremos se atingir o mesmo URL agora está retornando a resposta simulada ou fragmentada.
curl -X POST --data '{ 'request': { 'url': '/get/user/1', 'method': 'GET' }, 'response': { 'status': 200, 'body': 'Here it is!
' }}' http://localhost:8080/__admin/mappings/new
Vamos tentar entender esta solicitação CURL primeiro:
- Estamos fazendo uma solicitação CURL POST para http: // localhost: 8080 / __ admin / mappings / new - agora, este é o local onde todos os mapeamentos serão armazenados para o servidor Wiremock que executamos / iniciamos por meio do arquivo JAR.
- Na solicitação Curl, estamos definindo parâmetros de solicitação como - URL e método de solicitação junto com o corpo da resposta na seção “resposta”. Isso simplesmente implica que sempre que uma solicitação GET vier com URL / get / user / 1, responda com o corpo de resposta especificado.
# 5) Depois que a resposta fragmentada for definida (com a ajuda da solicitação curl acima), podemos tentar acessar a URL e ver se estamos obtendo a resposta fragmentada do Wiremock.
Vamos tentar acessar este URL no navegador - http: // localhost: 8080 / get / user / 1
Se o mapeamento foi definido com sucesso, você deve obter uma resposta conforme mostrado abaixo:
Junto com testes JUnit como configuração de regra JUnit
O servidor Wiremock pode ser usado com testes JUnit como uma configuração de regra JUnit. Com isso, a JUnit cuida do ciclo de vida da Wiremock, ou seja, a Wiremock inicia e pára.
Qual das opções a seguir não é uma maneira aceitável de testar um design responsivo?
É usado principalmente em configurações em que você gostaria de iniciar e parar o servidor após cada teste.
Isso tem suas próprias vantagens de ser isolado e tem um alto grau de configurabilidade em oposição a uma configuração autônoma onde várias pessoas podem acabar usando o mesmo servidor e passar por cima das respostas fragmentadas umas das outras.
Vejamos um exemplo prático dessa abordagem:
# 1) Crie uma regra JUnit para o servidor Wiremock. Esta etapa é essencialmente como uma etapa de configuração de teste em que estamos dizendo ao executor JUnit para instanciar o servidor Wiremock antes de cada teste e parar o servidor após cada teste.
O que isso também significa é que o executor JUnit se encarregará de iniciar e interromper o servidor Wiremock, sem fazer isso explicitamente.
@Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080));
#dois) Agora vamos escrever nosso teste em que primeiro criaremos nosso cliente (usando okHttp) para executar solicitações no endpoint desejado.
// execute request through http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build();
# 3) Porém, você pode observar aqui que ainda não definimos nenhum stub a ser devolvido para nossa instância Wiremock. ou seja, o cliente acima solicitará um URL http: // localhost: 8080 / test / abc que não possui nenhum stub configurado. Nesse caso, o servidor Wiremock retornará um 404 sem conteúdo.
# 4) Agora, a fim de definir um stub para a URL acima para nossa instância do servidor Wiremock, teremos que chamar os métodos estáticos de stub do Wiremock conforme mostrado abaixo.
private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); }
Aqui, você pode ver que usamos alguns métodos estáticos, como configureFor, stubFor etc. Todos esses métodos fazem parte da biblioteca Wiremock Java. (Veremos esses métodos em detalhes em nosso próximo tutorial / seções)
# 5) Agora, com a etapa de configuração concluída, podemos simplesmente executar a solicitação por meio do cliente e validar a resposta (dependendo do que estiver configurado para o stub retornar por meio do Wiremock)
Para resumir, aqui está como todo o exemplo de código seria:
public class WiremockJunitTest { @Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); @Test public void assertWiremockSetup() throws IOException { // Arrange - setup wiremock stubs configureStubs(); // execute request through the http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); // Act - call the endpoint Response response = client.newCall(request).execute(); // Assert - verify the response assertEquals('Test success!', response.body().string()); verify(exactly(1),getRequestedFor(urlEqualTo('/test/abc'))); } // configure stubs for wiremock private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } }
Dependências necessárias
Ele está disponível como:
- Um JAR autônomo contendo apenas a dependência Wiremock.
- Um grande frasco contendo Wiremock e todas as suas dependências.
Ambos os tipos estão disponíveis como dependências Gradle e Maven. Mais detalhes estão disponíveis no repositório oficial Maven aqui
Tutorial em vídeo: Wiremock com teste JUnit
Conclusão
Neste tutorial, examinamos os recursos básicos do Wiremock e vimos como ele pode ser executado como um servidor autônomo e como parte dos testes JUnit usando regras JUnit.
Também tocamos em stub em breve e vamos abordá-lo em detalhes em nosso próximo tutorial.
PRÓXIMO Tutorial
Leitura recomendada
- Introdução ao Micro Focus LoadRunner - Teste de carga com LoadRunner Tutorial # 1
- Tutorial do Ngrok: uma breve introdução com instalação e configuração
- Tutorial TestNG: Introdução ao Framework TestNG
- Introdução ao Selenium WebDriver - Selenium Tutorial # 8
- Introdução à linguagem de programação Java - tutorial em vídeo
- Introdução ao Python e processo de instalação
- O que é Unix: uma breve introdução ao Unix
- Tutorial do Neoload: Introdução, download e instalação do Neoload