Comment simuler une API REST?

Je travaille sur un nouveau projet qui interrogera les données d'une API REST tierce. Il s'agit d'un flux de données sportives en temps réel, donc le flux ne fonctionne que lorsqu'un jeu se déroule réellement.

Bien que la tierce partie fournisse une bonne documentation (XSD, etc.), ils n'ont aucun moyen de simuler un jeu, et donc pour tester le code que j'ai écrit contre cette API, je devrais attendre qu'un jeu réel se produise.

Mon seul recours est d'écrire du code pour simuler un jeu par moi-même, mais cela me semble beaucoup de travail. Comment aborderiez-vous cela?

C'est le cas d'utilisation parfait pour un faux objet . Il existe des bibliothèques moqueuses pour chaque langue populaire. Vous souhaitez vous moquer de l'objet qui fournit les réponses du service REST pour renvoyer les données de test. Vous pouvez soit générer manuellement les données de test, soit les collecter lors d'appels précédents au système en direct.

Attendez qu'un match se passe. Capturez chaque événement du flux. Écrivez un simulateur qui relit les événements aux moments appropriés. Voila, vous avez un simulateur de flux avec des données réelles.

Je recommande d'écrire votre propre simulateur. Vous pouvez l'utiliser pour tester toutes sortes de scénarios;

• Le serveur accepte la connexion mais ne répond pas
• Expiration du serveur
• Le serveur renvoie la réponse aux ordures, etc.

Lorsque j'ai fait cela dans le passé, j'ai utilisé des valeurs "spéciales" dans les messages de demande pour inviter le simulateur à faire ce dont j'ai besoin. Cela permet également d'exécuter des tests de bout en bout sans sortir de votre environnement de développement.

Modifier: Par exemple, si votre projet soumet XML à un service tiers, la demande peut inclure par exemple <value>50.00</value>. Le simulateur peut être codé (ou, mieux, configuré) de sorte que 50,00 => explose, 60,00 => ordures, 70,00 => ferme la connexion, etc. L'idée est que le comportement du simulateur dépend de son entrée, que vous contrôlez dans chaque cas de test.

Considérant que probablement le bookmaker fournit exemples de données (et cela peut être enregistré pendant la phase d'intégration), mon conseil est d'organiser ces flux de cette manière:

• Liste des événements
• Mises à jour pour les événements planifiés
• Mises à jour des cotes
• Résultats

Le fournisseur propose probablement 2 types de mises à jour: Push (POST) et Pull (GET).

À ce stade, vous devez

1. Créez un serveur simple qui ne gère que les requêtes GET, afin que vos programmeurs puissent élaborer des algorithmes.
2. Créez une automatisation pour gérer les soumissions des mêmes informations et ainsi stresser votre système.

Gérer le développement et les tests

Sans entrer dans les détails de la technologie à utiliser, vous obtenez un mini-serveur , qui ne répond qu'à 4 URL (ou celles nécessaires selon l'offre du fournisseur), et un service mini-push .

Une très bonne chose à garder à l'esprit lorsque vous travaillez avec le "mini-serveur", sont les gestionnaires du protocole HTTP. Créer un serveur sur le port 80 est très simple et résout le problème. Vous devez être sûr d'injecter toutes les informations dans les réponses GET comme le fait le fournisseur (cela évitera les problèmes lors de la mise en production).

Personnellement je ferais un simple serveur Perl ou pareil mais avec Nodejs. En ce qui concerne l'injection de données, sera suffisant un temporisateur, qui invoque un navigateur hors ligne ( CURL , WGET )

J'ai simulé l'API REST en utilisant une combinaison de cucumberjs, phantomjs avec la configuration du serveur proxy sur 127.0.0.1 et le raccordement d'un processus node.js avec http-proxyetnock là. CucumberJS n'est pas la partie importante, vous pouvez écrire un scénario de test de toute façon, le reste est la clé de la simulation. Il est capable de se moquer simplement par match-request-return-data, mais vous pouvez également filtrer par modèles et fonction de rappel de crochet pour produire une réponse, de sorte que vous pouvez simuler à n'importe quel niveau de granularité dont vous avez besoin (en fin extrême avec un serveur de démonstration complet, mais vous pouvez le faire progressivement).

Cela fonctionne bien:

1. Phantomjs demande un URI.
2. La demande est envoyée au serveur proxy sur 127.0.0.1:port.
3. Votre processus node.js procède à un transfert transparent en utilisant http-proxy. Ainsi, tout chargement "normal" (pages, images) fonctionne.
4. Si vous choisissez d'intercepter certaines requêtes (API, principalement), vous l'utilisez nock.

Dans mon scénario, je l'ai combiné avec des tests js de concombre dans le même processus, donc ça s'est passé comme suit:

1. Essais.
2. Il configure le nockmocking HTTP pour le scénario qu'il teste.
3. Il charge une page dans phantomjs via le protocole Selenium.

Le reste est comme indiqué plus haut dans ce paragraphe (c'est-à-dire que c'est un peu un cycle, je, en tant que testeur, demande aux phantomjs de charger une page, qui me renvoie toutes les demandes et je les transmets au réseau; ou intercepter si c'est l'API testée).