Simulieren Sie Dienste von Drittanbietern in application-go + BDD-Java

Was Ihnen der PHP-Editor Zimo heute vorstellen wird, ist die Methode zur Simulation von Drittanbieterdiensten in application-go + BDD-java. Während der Softwareentwicklung müssen wir häufig mit Diensten Dritter interagieren, während der Testphase haben wir jedoch möglicherweise keinen direkten Zugriff auf diese Dienste. Um dieses Problem zu lösen, können wir application-go und BDD-java verwenden, um das Verhalten von Drittanbieterdiensten zu simulieren und so effektivere Tests zu ermöglichen. Schauen wir uns als Nächstes die spezifische Implementierungsmethode an!

Frageninhalt

Ich habe vor kurzem mit der Recherche zu BDD begonnen (mit Gherkin + Restassured). Ich muss die Wartung durch Dritte simulieren. Das Folgende ist mein Anwendungsfall.

1. Service A ruft Service B intern auf
2. Die App befindet sich in goLang.
3. BDD verwendet die Java-Sprache.

Bei uns läuft eine CI-Pipeline, die das RPM generiert und das RPM in der virtuellen Maschine bereitstellt. Auf dieser VM führen wir BDD aus (Derzeit werden Service-A und Service-B auf derselben VM bereitgestellt)

Gibt es eine Möglichkeit, Service-B zu verspotten, sodass ich mich nicht auf Service-B verlassen muss? Wenn ja, was ist hier der beste Ansatz?

Habe goLang httptest ausprobiert, um den Dienst auf Unit-Test-Ebene zu simulieren. Aber wie simuliert man nach dem Erstellen von RPM in der Pipeline mithilfe von BDD?

Vielen Dank

Problemumgehung

Wenn Ihr Dienst A Dienst B intern und nicht über das Web oder RPC aufruft, können Sie die Abhängigkeitsinjektion verwenden, um eine „gefälschte“ Version von Dienst B einzuschleusen. (Beachten Sie, dass es sich dabei nicht unbedingt um Abhängigkeitsinjektions-Frameworks handelt; konstruktorbasierte und eigenschaftsbasierte Injektion sind ebenfalls gültig.) Wenn Dienst B keine Schnittstelle hat, extrahieren Sie eine und verwenden Sie einen Thin-Adapter, um je nach Umgebung den echten Dienst oder den gefälschten Dienst aufzurufen.

Solange die Szene nur mit der Benutzeroberfläche oder API von Service A interagiert, müssen Sie die Szene nicht ändern.

Sie müssen die Funktionsweise Ihrer Build-Pipeline ändern, sodass sie Ihren gefälschten Code anstelle Ihres echten Codes für die Bereitstellung verwendet.

Sie können dies sogar zur Laufzeit tun und von der Fälschung zur Realität wechseln, indem Sie den Adapter den entsprechenden Dienst aufrufen lassen. Der Wechsel oder die Bereitstellung kann durch Umgebungsvariablen oder Build-Parameter ausgelöst werden.

Aber bitte achten Sie darauf, Testdienste nicht in der Produktion einzusetzen!

Wenn Sie eine kontinuierliche Bereitstellung verwenden, sollte der letzte Schritt in der Build-Pipeline idealerweise die Bereitstellung und den Test der Interaktion mit dem eigentlichen Dienst sein. Wenn dies aus irgendeinem Grund Ihre einzige Arbeitsweise ist, gibt es dennoch ein paar Dinge, die Ihnen helfen könnten:

• Sie können die von Dienst B verwendeten Daten stutzen, damit sie sich auf vorhersehbare Weise verhalten

• Sie können Testinstanzen verwenden. Bitte wenden Sie sich an Ihren Dienstanbieter, um zu erfahren, ob er einen Dienst anbietet, der für Sie geeignet sein könnte. Ich würde vorschlagen, dass Sie dennoch überprüfen, ob die Bereitstellung des eigentlichen Dienstes erfolgreich war, vorzugsweise mithilfe einer Art automatisierter Tests, auch wenn dieser in der Produktion ausgeführt werden muss. Führen Sie einfach einen einfachen Rauchtest durch, um zu überprüfen, ob Ihr System angeschlossen ist. Beachten Sie, dass je einfacher die Bereitstellung ist, desto einfacher ist die Wiederherstellung nach Fehlern. Wenn Sie die Bereitstellung nicht schnell durchführen können, sind gründlichere Inspektionen erforderlich.

Wenn das RPM ohne irgendeine gefälschte oder Testinstanz erstellt und bereitgestellt wird und Sie die Umgebung nicht für die Verwendung einer solchen gefälschten oder Testinstanz konfigurieren können, können Sie es nicht verspotten. Die Build-Pipeline muss Teil der Bereitstellungsfälschung sein. Wenn Sie die Kontrolle über die CI-Pipeline haben, stellt dies ansonsten kein Problem dar. Wenden Sie sich an Ihr Build-Team. Sie haben möglicherweise Erfahrung oder können Sie an andere verweisen, die Ihnen helfen können. Schließlich wird großartiges BDD durch Dialoge vorangetrieben!

Das obige ist der detaillierte Inhalt vonSimulieren Sie Dienste von Drittanbietern in application-go + BDD-Java. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!