Server Vertrag Muster

Im Folgenden finden Sie eine Übersicht auf hoher Ebene für den Workflow von Vertragstests zwischen einem Consumer und einem Anbieterteam. Um diese Fälle abzufangen und den API-Vertrag für den Anbieter durchzusetzen, bevor er überhaupt eine Veröffentlichung durchsetzt, lädt der Anbieter in seiner CI-Pipeline die Verträge aller seiner Verbraucher herunter und führt die erforderlichen Anbietertests durch, um zu bestätigen, dass er nichts kaputt gemacht hat. Dieses Muster wird ideal zusammen mit der Service Fassade angewendet, um bei Bedarf neue Verträge zu unterstützen. In der CI-Phase richten wir eine Umgebung ein, die die Produktion so weit wie möglich repliziert, aber gemäß dem Geist von verbraucherorientierten Verträgen werden echte Instanzen von API-Anbietern nicht ausgegliedert. Wir verwenden Docker-basierte Container und Spin-up-Consumer-Container, die in der Build-Phase vor der Hand erstellt wurden, sowie Spin-up alle relevanten Datenbanken, die direkte Abhängigkeiten des Verbrauchers sind. Vertragsbedingungen sollten bei der Ausführung eines fehlerfreien Programms niemals verletzt werden. Verträge werden daher in der Regel nur während der Softwareentwicklung im Debugmodus überprüft. Später bei der Veröffentlichung werden die Vertragsprüfungen deaktiviert, um die Leistung zu maximieren. Die Status- und uponReceiving-Eigenschaften sind ebenfalls wichtig, da sie definieren, was die Anforderung ist (über die Testfallebene hinaus) und den Status, den der Anbieter erfüllen soll. Weitere Informationen zum Status in der Anbietervertragsprüfung. Dann nur die Stubs, die unter einem Pfad registriert sind, der bar-consumer im Namen enthält (d. h. die Stubs aus dem src/test/resources/contracts/bar-consumer/some/contracts/…

Ordner) dürfen referenziert werden. In der Buildphase ziehen wir den Code im Grunde von GitHub, führen grundlegende statische Codestil- und Qualitätsanalysen aus, die allgemein als Linting bezeichnet werden, und führen dann Komponententests, Vertragstests und Integrationstests durch. Vertragstests werden wie Komponententests ausgeführt, aber sie werden als eine weitere Buildaufgabe ausgeführt, nur um zu unterscheiden. Die Ausgabenachricht kann ausgelöst werden, indem eine Methode aufgerufen wird (z. B. ein Scheduler, wenn ein Vertrag gestartet und eine Nachricht gesendet wurde), wie im folgenden Beispiel gezeigt: Dies bedeutet, dass die Consumertests verwendet werden, um den Vertrag zu definieren, und Komponenten, die den Clientcode des Verbrauchers für die Interaktion mit dem Anbieter testen, aber keinen wirklichen Grund haben, zu scheitern. Ein gebrochener Vertrag scheitert nicht am Build oder CI des Verbrauchers, denn wenn die Verbrauchertests laufen, arbeiten sie mit dem Scheindienst des Pakts und spinnen keinen echten Anbieter aus. Sobald alle Interaktionen ausgeführt wurden, werden die Ergebnisse nach einer erfolgreichen oder fehlgeschlagenen Vertragstestsitzung an den Pakt-Broker zurückgesendet, wo sie zur Inspektion und Sichtbarkeit dieser Einsicht aufgezeichnet werden. Im Wesentlichen gibt es also einen Anbieter-API-Dienst, der instanziiert ist und darauf wartet, Anforderungen zu bearbeiten. Der Paktrahmen trägt dazu bei, diese Anträge zu übermitteln, und da er jeden einzelnen sendet, überprüft er auch, ob die Antwort den im Vertrag festgelegten Erwartungen entspricht – also der Interaktion. Ungeachtet solcher Zwänge wird der Umfang eines Vertrags einfach durch den Zusammenhalt seiner Mitgliedselemente bestimmt. Ein Vertrag kann viele Elemente enthalten und einen breiten Umfang haben oder sich nur auf wenige beschränken, solange er eine gewisse Geschäftsfunktionsfähigkeit zum Ausdruck bringt.

Das generierte Dokument (in diesem Fall in Asciidoc formatiert) enthält einen formatierten Vertrag. Der Speicherort dieser Datei wäre index/dsl-contract.adoc.