Simuler des services tiers dans application-go + BDD-java

Ce que l'éditeur PHP Zimo vous présentera aujourd'hui, c'est la méthode de simulation de services tiers en application-go + BDD-java. Lors du développement de logiciels, nous devons souvent interagir avec des services tiers, mais pendant la phase de test, il se peut que nous n'ayons pas accès directement à ces services. Pour résoudre ce problème, nous pouvons utiliser application-go et BDD-java pour simuler le comportement de services tiers afin de tester plus efficacement. Examinons ensuite la méthode de mise en œuvre spécifique !

Contenu de la question

J'ai récemment commencé des recherches sur BDD (en utilisant Gherkin + Restassured). Besoin de simuler un service tiers, voici mon cas d'utilisation.

1. Le service A appelle le service B en interne
2. L'application est située dans goLang.
3. BDD utilise le langage Java.

Nous avons un pipeline CI en cours d'exécution qui génère le RPM et déploie le RPM dans la machine virtuelle. Sur cette VM, nous exécutons BDD (actuellement Service-A et Service-B sont déployés sur la même VM)

Existe-t-il un moyen de se moquer du Service-B pour ne pas avoir à compter sur le Service-B ? Si oui, quelle est la meilleure approche ici.

J'ai essayé goLang httptest pour se moquer du service au niveau des tests unitaires. Mais comment simuler après avoir créé un rpm dans un pipeline à l'aide de BDD.

Merci

Solution de contournement

Si votre service A appelle le service B en interne, plutôt que via le Web ou RPC, vous pouvez alors utiliser l'injection de dépendances pour injecter une "fausse" version du service B. (Notez que cela n'implique pas nécessairement des frameworks d'injection de dépendances ; l'injection basée sur le constructeur et basée sur les propriétés sont également valides). Si le service B n'a pas d'interface, extrayez-en une et utilisez un adaptateur fin pour appeler le vrai service ou le faux service selon l'environnement.

Tant que la scène interagit uniquement avec l'interface utilisateur ou l'API du service A, vous n'avez pas besoin de changer de scène.

Vous devrez modifier le fonctionnement de votre pipeline de build afin qu'il utilise votre faux code pour le déploiement au lieu de votre vrai code.

Vous pouvez même le faire au moment de l'exécution, en passant du faux au vrai en demandant à l'adaptateur d'appeler le service concerné. La commutation ou le déploiement peut être déclenché par des variables d'environnement ou des paramètres de construction.

Mais veillez à ne pas déployer de services de test en production !

Si vous utilisez un déploiement continu, idéalement, la dernière étape du pipeline de build devrait déployer et tester l'interaction avec le service réel. Si, pour une raison quelconque, c'est la seule façon dont vous travaillez, il y a encore quelques choses que vous pouvez faire et qui pourraient vous aider :

• Vous pouvez supprimer les données utilisées par le service B afin qu'elles se comportent de manière prévisible

• Vous pouvez utiliser des instances de test. Veuillez contacter votre fournisseur de services pour voir s'il propose des services qui pourraient vous convenir. Je suggère que vous devriez toujours vérifier si le déploiement du service réel a réussi, de préférence en utilisant une sorte de test automatisé, même s'il doit être exécuté en production. Faites simplement un test de fumée de base pour vérifier si votre système est connecté. Notez que plus il est facile à déployer, plus il est facile de récupérer des erreurs ; si vous ne pouvez pas déployer rapidement, vous aurez besoin d'inspections plus approfondies.

Si le RPM est créé et déployé sans aucune sorte d'instance fausse ou de test, et que vous ne pouvez pas configurer l'environnement pour utiliser une telle instance fausse ou de test, vous ne pourrez pas vous en moquer. Le pipeline de build doit faire partie de la contrefaçon de déploiement. Si vous contrôlez le pipeline CI, cela ne posera pas de problème ; sinon, contactez votre équipe de build. Ils peuvent avoir de l'expérience ou être en mesure de vous référer à d'autres personnes qui peuvent vous aider. Après tout, un bon BDD est motivé par le dialogue !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!