Como simular uma API REST?

Estou trabalhando em um novo projeto que consultará dados de uma API REST de terceiros. Isso é para um feed de dados esportivos em tempo real; portanto, o feed só funciona quando um jogo está realmente acontecendo.

Embora a terceira parte forneça boa documentação (XSD, etc), eles não têm como simular um jogo, e, para testar o código que escrevi nessa API, precisaria esperar que um jogo real acontecesse.

Meu único recurso é escrever código para simular um jogo sozinho, mas parece muito trabalho. Como você abordaria isso?

Este é o caso de uso perfeito para um objeto simulado . Existem bibliotecas de zombaria para todos os idiomas populares. Você deseja zombar do objeto que fornece as respostas do serviço REST para retornar dados de teste. Você pode gerar manualmente os dados de teste ou coletá-los de chamadas anteriores para o sistema ativo.

Aguarde até que um jogo esteja acontecendo. Capture todos os eventos do feed. Escreva um simulador que repita os eventos nos momentos apropriados. Você tem um simulador de feeds com dados reais.

Eu recomendo escrever seu próprio simulador. Você pode usá-lo para testar todos os tipos de cenários;

• O servidor aceita conexão, mas não responde
• Tempo limite do servidor
• Servidor enviar resposta de lixo etc ...

Quando eu fiz isso no passado, usei valores "especiais" nas mensagens de solicitação para solicitar ao simulador que fizesse o que eu precisava. Isso também possibilita a execução de testes de ponta a ponta sem sair do ambiente de desenvolvimento.

Editar: por exemplo, se o seu projeto enviar XML para um serviço de terceiros, a solicitação poderá incluir, por exemplo <value>50.00</value>. O simulador pode ser codificado (ou, melhor, configurado) para que 50,00 => exploda, 60,00 => lixo, 70,00 => feche a conexão e assim por diante. A ideia é que o comportamento do simulador dependa de sua entrada, que você controla em cada caso de teste.

Considerando que provavelmente a casa de apostas fornece alguns dados de amostra (e isso pode ser salvo durante a fase de integração), meu conselho é organizar esses feeds da seguinte maneira:

• Lista de eventos
• Atualizações para eventos agendados
• Atualizações de probabilidades
• Resultados

Provavelmente, o provedor oferece 2 tipos de atualizações: Push (POST) e Pull (GET).

Neste ponto, você deve

1. Crie um servidor simples que apenas lide com solicitações GET, para que seus programadores possam elaborar algoritmos.
2. Crie uma automação para gerenciar envios das mesmas informações e, assim, estressar o sistema.

Gerenciar o desenvolvimento e testes

Sem entrar nos detalhes da tecnologia a ser usada, você obtém um mini-servidor , que responde apenas a 4 URLs (ou os necessários, dependendo do que o provedor oferece) e um serviço de mini-push .

Uma coisa muito boa a ter em mente ao trabalhar com o "mini-servidor", são os manipuladores do protocolo HTTP. Criar um servidor na porta 80 é muito simples e resolve o problema. Você deve certificar-se de injetar todas as informações nas respostas GET conforme o fornecedor faz (isso evitará problemas quando colocado em produção).

Pessoalmente, eu faria um servidor Perl simples ou o mesmo, mas com o Nodejs. No que diz respeito à injeção de dados, será suficiente um temporizador, que invoque um navegador offline ( CURL , WGET )

Simulei a API REST usando a combinação de cucumberjs, phantomjs com a configuração do servidor proxy como 127.0.0.1 e conectando um processo node.js com http-proxye nockali. CucumberJS não é a parte importante, você pode escrever o cenário de teste de qualquer maneira, o resto é a chave para a simulação. Ele pode simular simplesmente por correspondência-solicitação-retorno-dados, mas você também pode filtrar por padrões e função de retorno de chamada para gerar uma resposta, para simular qualquer nível de granularidade necessário (em extremo extremo com um servidor de demonstração completo, mas você pode fazê-lo de forma incremental).

Funciona bem:

1. Os Phantomjs solicitam um URI.
2. A solicitação vai para o servidor proxy em 127.0.0.1:port.
3. Seu node.js processa proxies que o encaminham de forma transparente usando http-proxy. Portanto, qualquer carregamento "normal" (páginas, imagens) funciona.
4. Se você optar por interceptar alguns pedidos (API, principalmente), você utilizará nockpara isso.

No meu cenário, eu o combinei com os testes js de pepino no mesmo processo, e foi assim:

1. Teste é executado.
2. Ele configura a nocksimulação de HTTP para o cenário que ele testa.
3. Carrega uma página em phantomjs via protocolo Selenium.

O restante é como mostrado anteriormente neste parágrafo (ou seja, é um ciclo, eu, como executor de teste, instruo os phantomjs a carregar uma página, que encaminha todas as solicitações de volta para mim e as encaminha para a rede; ou intercepto se for a API testada).