Voici comment tester les API externes dans Elixir avec Bypass

Nous accordons la priorité aux principes de l’architecture axée sur le service à Inverse. Cela signifie que nous avons des composants de petite taille et maintenables avec des responsabilités clairement définies. Ils communiquent (principalement) les uns avec les autres, via des API de type Representational State Transfer ou REST.

Cela offre une flexibilité et nous a bien servi, à l'exception d'un aspect important: les tests. Lors des tests, il faut éviter:

• Dépendance à l'égard de services externes s'exécutant sur le même ordinateur.
• Tests lents.

Étant donné que les applications reposent de manière inhérente sur des services externes, il est essentiel de mettre en place une stratégie de test pour ces dépendances.

Nous avons récemment commencé à utiliser Bypass et je vais expliquer comment nous y sommes arrivés et plus précisément comment nous l’utilisons.

Le passé

Simulez des méthodes et renvoyez des exemples de données comme celui-ci:

C'était (et je crois toujours) le «chemin à parcourir» dans le monde de Ruby / Rails. Malheureusement, cela encourage les mauvais comportements, comme l'explique ici José Valim.

Nous avons ensuite commencé à utiliser ExVCR, qui est une excellente bibliothèque, mais présente des inconvénients similaires à ceux de moqueurs / talons: cela encourage la paresse et ne favorise pas la séparation des problèmes essentiels à des API bien définies. ExVCR permet de “enregistrer” et de “reproduire” des données en temps réel. C’est très facile à intégrer (y compris quelques lignes dans votre test et tout le reste est pris en charge). Mais idéalement, vous devez penser aux dépendances externes dans les tests, et non les résumer. Cela pourrait toujours être un choix viable pour les scénarios dans lesquels le comportement du point de terminaison doit être testé avec une surcharge minimale (nous l’utilisons pour tester les appels aux services AWS d’Amazon tels que S3).

Entrer des adaptateurs

Les adaptateurs fonctionnent très bien et favorisent la discussion autour des contrats d’API et des limites de communication clairement définies. Nous utilisons toujours cette approche, en particulier lorsque l’adaptateur est plus complexe (comme un socket JSON-RPC).

Voici à quoi pourrait ressembler un adaptateur:

Mais pour les points de terminaison HTTP simples, les adaptateurs semblent demander beaucoup de travail et présentent un inconvénient majeur: ils laissent les bibliothèques qu’ils consomment en dehors de l’équation de test. Si quelque chose change dans les bibliothèques HTTP ou JSON, les tests ne l’arrêteront pas. La quantité de code critique pour la production qui n'a pas été testée par cette approche est inacceptable.

Le présent et le futur

Bypass nous permet de démarrer un serveur Web très simple lors de tests simulant des services externes que nous utilisons.

Nous pouvons maintenant tester l’ensemble de la pile, y compris la bibliothèque HTTP, la bibliothèque de codage / décodage JSON et les mécanismes d’authentification. Le fichier README de Bypass est bien écrit, je vais donc épargner les détails de la mise en œuvre. Nous modifions toutefois légèrement notre utilisation afin de garder les tests concis et lisibles:

Tout d'abord, nous souhaitons parfois appeler Facebook lorsque des tests sont exécutés en tant que suite d'intégration complète. Nous procédons de manière irrégulière pour nous assurer que l'API de Facebook fonctionne toujours conformément à nos attentes. Ajouter --inclure l'intégration à test de mélange ne simule pas l'API, mais appelle le service externe (lignes 5, 7).

Nous sommes explicites lorsque nous simulons des demandes adressées à des services externes, de sorte que chaque test utilisant Bypass doit avoir la @tag facebook_bypass (ligne 7).

Finalement, le handle_fb fonction (lignes 30 à 39) est appelée (étant donné que le request_path allumettes). J'aime faire correspondre la tête de la fonction car elle indique explicitement le chemin auquel nous réagissons et nous permet de définir différentes fonctions pour différents chemins.

Donc, Bypass ne fonctionne que sur les tests marqués avec @tag: contourner et lorsque nous n'exécutons pas notre suite d'intégration. Une autre chose que nous faisons lors de la configuration de Bypass est de permettre à la balise de transmettre un identifiant de page (lignes 8, 20). Voici comment se présente un test utilisant Bypass:

Comme vous pouvez le voir, le facebook_bypass La balise indique explicitement que nous simulons l'API (sauf si nous sommes en mode d'intégration). Cela nous permet de transmettre des informations à l’API simulée et il est très facile de réutiliser la même configuration de contournement pour différents tests.

J'espère que cela vous aide à tester les API externes. Vous pouvez me trouver sur Twitter (voir ci-dessous) si vous avez d'autres questions.