01 / Vertragsprüfung
Benennen Sie die Baseline und den Kandidaten richtig
Die Basis ist der Vertrag, den bestehende Verbraucher bereits nutzen; Der Kandidat ist der vorgeschlagene Ersatz. Diese Richtung ist wichtig, da das Entfernen einer Operation oder das Einschränken eines akzeptierten Werts einen anderen Kompatibilitätseffekt hat als das Hinzufügen einer Operation.
Halten Sie die Quellversionen während der Überprüfung verfügbar. Eine Regelübereinstimmung ist ein Beweis für eine Freigabeentscheidung und kein Ersatz für das Verständnis des betroffenen Verbraucherworkflows.
02 / Vertragsprüfung
Trennen Sie wahrscheinliche Unterbrechungen von kontextabhängigen Änderungen
Überprüfen Sie zunächst entfernte oder neu erforderliche Vertragselemente und untersuchen Sie dann Änderungen, deren Auswirkungen vom Verbraucherverhalten oder der Laufzeitsemantik abhängen. Kompatible Ergänzungen verdienen dennoch eine Überprüfung, wenn undokumentiertes Verhalten oder eine benutzerdefinierte Validierung vorliegt.
Der Vergleich beschreibt den Vertrag, den er analysieren kann. Laufzeitverhalten, Serverimplementierung und undokumentierte Erwartungen bleiben außerhalb dieser Beweise.
- Beginnen Sie mit entfernten Pfaden, Operationen, Parametern, Eigenschaften und Enumerationswerten.
- Überprüfen Sie neue Anforderungen und engere Typen.
- Behandeln Sie semantisches Verhalten als menschliche Überprüfungsgrenze.
03 / Vertragsprüfung
Ein CI-Job schlägt nur bei wichtigen Änderungen fehl
Führen Sie mit Pro diff-anything --cli --mode api --fail-on breaking aus oder legen Sie failOn: breaking für einen Fall in einem Batch-Manifest fest, unter Windows oder, mit dem kostenlosen Befehlszeilenhilfsprogramm, auf dem Mac. Identische oder äquivalente Schemata bestehen die Prüfung, kompatible Änderungen sind zulässig, und der Job schlägt bei inkompatiblen Änderungen und bei Änderungen fehl, die die Regeln nicht klassifizieren konnten. Die JUnit- und SARIF-Ausgabe listet jedes Ergebnis mit seinem Regelcode auf, z. B. API001 für einen entfernten Vorgang.
Die Regeln sind heuristisch: $ref wird als geschrieben und nicht als gelöst verglichen, Anforderungs- und Antwortschemata werden gleich behandelt und einige inkompatible Änderungen werden nicht klassifiziert, z. B. ein entfernter Komponenteneintrag, ein umbenannter oder verschobener Parameter oder hinzugefügte zusätzliche Eigenschaften: false. Behandeln Sie eine bestandene Prüfung als erstes Tor und nicht als Kompatibilitätsnachweis und behalten Sie lokal und in CI die gleiche Grundlinienrichtung bei.
Das Befehlszeilenhilfsprogramm für den Mac herunterladen →
