¿Cómo simular una API REST?

Estoy trabajando en un nuevo proyecto que consultará datos de una API REST de terceros. Esto es para un feed de datos deportivos en tiempo real, por lo que el feed solo funciona cuando un juego se está llevando a cabo.

Aunque la tercera parte proporciona una buena documentación (XSD, etc.), no tienen forma de simular que suceda un juego, por lo que para probar el código que escribí en esta API, tendría que esperar a que suceda un juego real.

Mi único recurso es escribir código para simular un juego por mi cuenta, pero parece mucho trabajo. ¿Cómo abordarías esto?

Este es el caso de uso perfecto para un objeto simulado . Hay bibliotecas burlonas para cada idioma popular. Desea burlarse del objeto que proporciona las respuestas del servicio REST para devolver datos de prueba. Puede generar manualmente los datos de prueba o recopilarlos de llamadas anteriores al sistema en vivo.

Espera hasta que ocurra un juego. Capture todos los eventos del feed. Escriba un simulador que reproduzca los eventos en los momentos apropiados. Voila, tienes un simulador de feed con datos reales.

Recomiendo escribir tu propio simulador. Puede usarlo para probar todo tipo de escenarios;

• El servidor acepta la conexión pero no responde
• El servidor agota el tiempo de espera
• El servidor devuelve la respuesta basura, etc.

Cuando hice esto en el pasado, usé valores "especiales" en los mensajes de solicitud para pedirle al simulador que haga lo que necesito. Esto también hace posible ejecutar pruebas de extremo a extremo sin salir de su entorno de desarrollo.

Editar: por ejemplo, si su proyecto envía XML a un servicio de terceros, la solicitud puede incluir, por ejemplo <value>50.00</value>. El simulador se puede codificar (o, mejor, configurar) de modo que 50.00 => explotar, 60.00 => basura, 70.00 => cerrar la conexión, y así sucesivamente. La idea es que el comportamiento del simulador depende de su entrada, que usted controla en cada caso de prueba.

Teniendo en cuenta que probablemente la casa de apuestas proporcione algunos datos de muestra (y esto se puede guardar durante la fase de integración), mi consejo es organizar esos feeds de esta manera:

• Lista de eventos
• Actualizaciones para eventos programados
• Actualizaciones de probabilidades
• Resultados

Probablemente, el proveedor ofrece 2 tipos de actualizaciones: Push (POST) y Pull (GET).

En este punto deberías

1. Cree un servidor simple que solo maneje las solicitudes GET, para que sus programadores puedan elaborar algoritmos.
2. Cree una automatización para administrar los envíos de la misma información y, por lo tanto, puede estresar su sistema.

Gestionar el desarrollo y las pruebas.

Sin entrar en los detalles de la tecnología que se utilizará, obtienes un mini servidor , que responde solo a 4 URL (o las necesarias según lo que ofrezca el proveedor), y un servicio mini-push .

Una cosa muy buena a tener en cuenta al trabajar con el "mini servidor" son los controladores del protocolo HTTP. Crear un servidor en el puerto 80 es muy simple y resuelve el problema. Debe asegurarse de inyectar toda la información en las respuestas GET según el proveedor (esto evitará problemas cuando se ponga en producción).

Personalmente, haría un servidor Perl simple o lo mismo pero con Nodejs. Con respecto a la inyección de datos, será suficiente un temporizador, que invoca un navegador fuera de línea ( CURL , WGET )

Simulé la API REST usando una combinación de cucumberjs, phantomjs con la configuración del servidor proxy en 127.0.0.1 y enganchando un proceso node.js con http-proxyy nockallí. CucumberJS no es la parte importante, puede escribir el escenario de prueba de cualquier manera, el resto es la clave de la simulación. Puede burlarse simplemente por datos de solicitud de devolución de coincidencias, pero también puede filtrar por patrones y enganchar la función de devolución de llamada para producir una respuesta, de modo que pueda simular cualquier nivel de granularidad que necesite (en extremo terminando con un servidor de demostración completo, pero puede hacerlo de forma incremental).

Funciona muy bien:

1. Phantomjs solicita un URI.
2. La solicitud va al servidor proxy en 127.0.0.1:port.
3. Su proceso node.js lo envía de forma transparente hacia adelante usando http-proxy. Entonces, cualquier carga "normal" (páginas, imágenes) funciona.
4. Si elige interceptar algunas solicitudes (API, principalmente) que usa nockpara ello.

En mi escenario, lo combiné con las pruebas de pepino js en el mismo proceso, por lo que fue como:

1. La prueba corre.
2. En él se establecen nockHTTP burla para el escenario se pone a prueba.
3. Carga una página en phantomjs a través del protocolo Selenium.

El resto es como se muestra anteriormente en este párrafo (es decir, es un poco un ciclo, yo, como corredor de prueba, le pido a phantomjs que cargue una página, que me reenvía todas las solicitudes y las reenvío a la red; o interceptar ellos si es la API probada).