Menü

Einführung in das Testen von Verträgen anhand von Beispielen

  • Haupt
  • Andere
  • Einführung in das Testen von Verträgen anhand von Beispielen

introduction contract testing with examples

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

bester Spyware-Entferner für Windows 10

In diesem Tutorial zum Testen von Paktverträgen wird erläutert, was verbraucherorientierte Vertragstests sind, wie sie funktionieren und warum Sie sie in Ihrer Teststrategie verwenden sollten:

Was ist Vertragstest?

Consumer-Driven Contract Testing ist eine Form des API-Testens, die eine Verschiebung nach links ermöglicht. Das Vertragswerkzeug, das wir verwenden, ist Pact.io und wir werden später in dieser Reihe von Tutorials davon erfahren.

Vertragstests sind eine Methode, um die Integration zwischen zwei Anwendungen unabhängig voneinander zu überprüfen, um zu testen, was bestanden wurde, und um festzustellen, ob das zurückgegebene Objekt mit dem „Vertrag“ übereinstimmt.

Vertragstests passen gut in eine Microservice-Architektur, die in einer agilen Umgebung arbeitet. Daher basieren Beispiele auf den Erfahrungen, die wir in dieser Umgebung gesammelt haben.

Vertragstests

Was du lernen wirst:

Liste der Tutorials in dieser Vertragstestreihe

Tutorial Nr. 1: Einführung in das Testen von Verträgen mit Beispielen (Dieses Tutorial)
Tutorial # 2: Wie schreibe ich einen Consumer Pact Test in JavaScript
Tutorial # 3: So veröffentlichen Sie einen Paktvertrag für Pact Broker
Tutorial # 4: Überprüfen Sie den Paktvertrag und die kontinuierliche Bereitstellung mit Pact CLI

Verbrauchergesteuerte Vertragstests

Der Ausgangspunkt ist Ihre API-Dokumentation, die den Vertrag für Ihre Tests bildet. Zu diesem Zeitpunkt nehmen die Entwicklungsteams normalerweise das API-Dokument und entwickeln es anhand des Wiki-Dokuments (oder des Formats, das sich in Ihrer Organisation befindet, z. B. Word-Dokument).

Beispielsweise, Eine Webanwendung, bei der das Front-End von Team Krypton und die API von Team Thoron entwickelt werden. Das Projekt beginnt mit einem Kick-off-Meeting, bei dem die Anforderungen präsentiert und zwischen den Teams vereinbart werden.

Jedes Team nimmt die Anforderungen an und beginnt mit der Erstellung des Rückstands, indem es die Storys verfeinert. Die Entwicklung beginnt in beiden Teams nach den User Stories. Integrationstests bleiben für spätere Sprints übrig. Da Team Krypton zusätzliche Anforderungen in Bezug auf Fehlerszenarien feststellt, wird die API-Dokumentation entsprechend aktualisiert.

Team Thoron fügt Testfälle hinzu, die sich auf die aktualisierten Szenarien beziehen, die auf der Dokumentation basieren.

Wir können bereits einige Fehler bei diesem Prozess feststellen, und ich habe zum Glück noch einige hinzugefügt:

  1. Änderungen an API-Dokumenten werden möglicherweise nicht effektiv kommuniziert.
  2. Das Front-End-Team beendet den Back-End-Service und umgekehrt.
  3. Das Back-End-Team erstellt Integrationstestfälle basierend auf der Dokumentation.
  4. Die Integrationsumgebung ist das erste Mal, dass die vollständige Integration getestet wird.
  5. Unterschiedliche API-Version in der Integrationsumgebung im Vergleich zur Produktion.

Verbrauchergesteuerte Vertragstests haben zwei Seiten, d. H. Den Verbraucher und den Anbieter. Hier wird das traditionelle Denken über das Testen in Microservices umgedreht.

Das Verbraucher ist der Kurator der Szenarien, einschließlich der Anfrage und der erwarteten Antwort. Dies ermöglicht es Ihnen zu folgen Bettgesetz Dies schreibt vor, dass Sie flexibel sein sollten, was Ihre API akzeptieren kann, aber konservativ, was gesendet wird. Zurück zu den Fehlern Nr. In den 1, 3 und 4 werden die Dokumentationsänderungen vom Verbraucher gesteuert.

Beispielsweise, Unter den Umständen, in denen Team Thoron ein Zeichenfolgenfeld so ändert, dass keine Nullwerte akzeptiert werden, spiegeln die Verbrauchertests die Änderung nicht wider und schlagen daher fehl. Oder zumindest bis die Änderungen am Team Krypton vorgenommen wurden.

Verbrauchererwartungen definieren

(Bild Quelle ))

Das Anbieter überprüft die vom Verbraucher bereitgestellten Szenarien anhand seiner Entwicklungsumgebung. Dies ermöglicht es Ihren Microservices, dies durchzusetzen Parallele Änderung Dies besagt, dass Sie die API-Funktionalität erweitern und anschließend auf eine neue Version migrieren sollten. Zurück zu Fehler Nr. 2, die Stubs, die normalerweise von den Back-End-Teams für ihre eigenen Testanforderungen erstellt werden, können jetzt auf den verwendeten Verbraucherszenarien basieren Pact Stub Server .

Überprüfen Sie die Erwartungen an den Anbieter

Das verbindliche Element der beiden Seiten ist der „Vertrag“, der zwischen den Teams geteilt werden muss. Der Pakt bietet eine Plattform für die gemeinsame Nutzung von Verträgen, die als Pakt bezeichnet werden Paktbroker (verfügbar als Managed Service mit Pactflow.io ).

Das Makler speichert die Ausgabe der Verbraucherszenarien. Der Vertrag wird dann im Broker zusammen mit der Version der API gespeichert. Dies ermöglicht das Testen mit mehreren Versionen der API, sodass die Kompatibilität vor der Veröffentlichung bestätigt werden kann, wie in Fehler Nr. 5 hervorgehoben.

pact_network_diagram
Pact Broker - Visuelle Darstellung

Ein zusätzlicher Vorteil für den Pact Broker auf den Legacy-Plattformen ist die Sichtbarkeit der Verbraucher. Den API-Autoren sind nicht alle Verbraucher bekannt, insbesondere nicht, wie es konsumiert wird.

Insbesondere in Bezug auf ein Ereignis, bei dem zwei API-Versionen unterstützt wurden, gab es in Version 1 (V1) ein Datenproblem, das durch die API verursacht wurde schmutzige Daten in der Datenbank.

Die Änderung wurde in Version 1 der API implementiert und in die Produktion übertragen. Der Verbraucher verließ sich jedoch auf das Format, das das Datenproblem verursachte, wodurch die Integration in die API unterbrochen wurde.

Wie funktioniert es

Authentifizierungsablauf

Das obige Beispiel zeigt den Authentifizierungsablauf. Der Webdienst erfordert, dass sich die Benutzer authentifizieren, um auf vertrauliche Daten zugreifen zu können. Der Webdienst sendet eine Anforderung an die API, um ein Token mit einem Benutzernamen und einem Kennwort zu generieren. Die API gibt ein Inhaber-Token zurück, das der Datenanforderung als Authentifizierungsheader hinzugefügt wird.

Der Consumer-Test erstellt eine POST-Anforderung für ein Token, indem der Body mit Benutzername und Kennwort übergeben wird.

POST-Anfrage

Während des Tests wird ein Mock-Server hochgefahren, der die von Ihnen erstellte Anforderung zusammen mit der erwarteten Antwort überprüft, die in diesem Beispiel den Wert für das Token enthält.

Mock-Server

Die Ausgabe des Verbrauchertests generiert eine Paktvertragsdatei. Dies wird im Pact Broker als Version 1 gespeichert.

Der Anbieter ruft dann Version 1 vom Pact Broker ab und spielt diese Anfrage mit seiner lokalen Umgebung ab, indem er überprüft, ob die Anfrage und die Antwort mit den Verbraucheranforderungen übereinstimmen.

Paktbroker

Rollen und Verantwortlichkeiten

Rollen und Verantwortlichkeiten

Qualitätssicherung (QS) / Tester: Erstellen von Verträgen mit Pact.io und Arbeiten mit der BA zum Generieren der Testszenarien.

Entwickler: Passen Sie mit den Qualitätssicherungsprogrammen zusammen, um die Tests zu erstellen und die API für die Implementierung in Continuous Integration (CI) zu verpacken.

Business Analyst (BA): Generieren der Szenarien und Arbeiten mit dem Architekten zur Überprüfung der betroffenen Parteien.

Lösungsarchitekt (Möglicherweise nicht in Ihrer Organisation vorhanden): Durchführen der API-Änderungen und Koordinieren mit der BA bei der Implementierung sowie Übermitteln von Änderungen an die Verbraucher (Verwenden des Pact Broker, um zu verstehen, wen es betrifft).

Release Management: (Ja, ich weiß, dass es altmodisch ist, aber in meiner Welt immer noch existiert.): Mit der Zuversicht erfüllt, dass Änderungen aufgrund der Abdeckung durch Vertragstests erfolgreich veröffentlicht werden.

Ganzes Team: Überprüfen Sie die Ergebnisse, um festzustellen, ob die Releases mit dem Pact CLI-Tool in die Produktion übertragen werden können. Kann ich bereitstellen? .

Vertragstests gegen Integrationstests

Integrationstests müssen vorhanden sein, um zu überprüfen, ob das System vor der Heraufstufung in die Produktionsumgebung funktioniert. Die Szenarien können jedoch erheblich reduziert werden.

Dies könnte folgende Auswirkungen haben:

  • Schnellere Rückmeldung vor der Freigabe an die Integrationsumgebung.
  • Weniger Vertrauen in die Stabilität der Integrationsumgebung.
  • Weniger Umgebungen, die mehrere API-Versionen unterstützen.
  • Reduzierte instabile Umgebungsinstanzen aufgrund von Integrationsproblemen.
IntegrationVertrag
Fehler genau lokalisierenViele SchichtenSehr leicht
API-KonfigurationJaNein
BereitstellungsprüfungenJaNein
API-VersionierungJaJa
Lokal debuggenNeinJa
UmweltproblemeJaNein
Feedback-ZeitSchleppendSchnell

Erstens ersetzen Vertragstests nicht Integrationstests. Aber es kann wahrscheinlich einige Ihrer vorhandenen Integrationstestszenarien ersetzen, nach links verschieben und schnelleres Feedback zu Ihrem Softwareentwicklungslebenszyklus geben.

Testfälle in Beispielen für Softwaretests

Beim Integrationstest überprüfen Sie den Kontext, in dem sich die API befindet, z. B. die Umgebungsarchitektur, den Bereitstellungsprozess usw.

Daher möchten Sie die Kerntestszenarien ausführen, die die Konfiguration bestätigen würden. zum Beispiel, Der Health Check-Endpunkt für die API-Version. Überprüfen Sie auch, ob die Bereitstellung erfolgreich war, indem Sie eine Antwort von 200 zurückgeben.

Beim Vertragstest testen Sie die Besonderheiten der API, einschließlich der Randfälle in Bezug auf die API-Struktur, den Inhalt (z. B. Feldwerte, Schlüssel vorhanden) und Fehlerantworten. Beispielsweise, Behandelt die API Nullwerte oder werden sie aus der API-Antwort entfernt (ein weiteres reales Beispiel)?

Einige Vorteile (falls Sie noch nicht verkauft sind)

Nachfolgend sind einige der Vorteile aufgeführt, die Sie beim Verkauf von Vertragstests an ein breiteres Unternehmen nutzen können:

  • Schnellere Bereitstellung von Software
  • Eine einzige Quelle der Wahrheit
  • Sichtbarkeit aller Verbraucher
  • Einfaches Testen gegen verschiedene API-Versionen.

Häufig gestellte Fragen

Einige häufig gestellte Fragen beim Versuch, Menschen zur Annahme von Vertragstests zu bewegen, sind:

F # 1) Wir haben bereits eine 100% ige Testabdeckung, sodass wir sie nicht benötigen.

Antworten: Nun, das ist unmöglich, aber Vertragstests haben viele andere Vorteile als nur die Testabdeckung.

F # 2) Es liegt in der Verantwortung des Solution Architect, API-Änderungen zu kommunizieren.

Antworten: Qualität liegt in der Verantwortung des gesamten Teams.

F # 3) Warum erstellen wir die Testszenarien für das API-Team?

Antworten: Das API-Team weiß nicht, wie der Webdienst funktioniert. Warum sollte er also dafür verantwortlich sein?

F # 4) Unsere End-to-End-Tests decken den gesamten Ablauf von Anfang bis Ende ab, einschließlich anderer Integrationspunkte.

Antworten: Genau deshalb teilen wir die Tests auf, um eine Sache zu testen, und es liegt nicht in Ihrer Verantwortung, den End-to-End-Ablauf eines Systems zu testen, von dem Sie nicht wissen, wie es funktioniert.

F # 5) In welchem ​​Team-Repository leben die Tests?

Antworten: Beide. Der Verbraucher in seinem Repository und der Anbieter in ihrem. Im zentralen Punkt lebt der Vertrag dann außerhalb eines von beiden.

Argumente

Dies sind die Argumente, gegen die wir beim Übergang zum Vertrag zum Testen nur schwer argumentieren können:

  • Bereits vorhandene Swagger-Dokumentation, mit der Integrationstests erstellt werden können.
  • Teams besitzen sowohl Front-End- als auch Back-End-Services mit einem effektiven Mechanismus für API-Änderungen.

Kontinuierliche Integration

Wie passt dies in Ihre Testsuite für kontinuierliche Integration? Der wünschenswerte Ort, an dem Vertragstests durchgeführt werden können, sind Ihre Komponententests.

Verbrauchertests starten einen Mock-Server, für den außerhalb des Tests keine externen Abhängigkeiten erforderlich sind.

Anbietertests erfordern eine API-Instanz, daher kann die lokale API mit einer umbrochen werden In-Memory-Testserver . Wenn es jedoch nicht einfach ist, Ihre API lokal zu verpacken, haben wir zuvor eine Umgebung umgangen und den Code als Teil der automatisierten Pull-Request-Überprüfungen in dieser Umgebung bereitgestellt.

Kontinuierliche Integration

Video zur kontinuierlichen Integration

Kontinuierliche Integration 3

(Bild Quelle ))

Fazit

In diesem Tutorial haben wir gelernt, was Vertragstests bedeuten und wie sie in einer Microservice-Infrastruktur aussehen, und wie sie in einem realen Beispiel aussehen.

Es wurden Lehren gezogen, wie Vertragstests Ihnen helfen können, Ihre Integrationstests nach links zu verschieben. Darüber hinaus haben wir gesehen, wie Sie die Kosten für Ihr Unternehmen senken können, indem Sie die Feedbackzeiten im Zusammenhang mit Integrationsproblemen verkürzen.

Vertragstests sind nicht nur ein Werkzeug für technische Tests, sondern erzwingen die Zusammenarbeit von Entwicklungsteams, indem sie Änderungen kommunizieren und Tests als eine Einheit fördern. Insgesamt sollte dies eine Voraussetzung für alle sein, die auf Continuous Deployment umsteigen möchten.

NÄCHSTES Tutorial

Literatur-Empfehlungen

^