Blind-Test-Suite
Die Suite ist ein unabhängiger, aus dem Vertrag abgeleiteter Nachweis, nicht die Definition der Konformität. Ein fehlschlagender Test sagt also, dass entweder die Implementierung oder der Test falsch ist – niemals der Vertrag.
test-writer entscheidet über die Form jedes Tests, und test-oracle-reviewer darüber, was als unabhängiger Wert zählt; diese Fähigkeit ist die Isolierung um sie herum.
Was der Autor sieht
Die Vertragsdatei, die Schnittstelle, gegen die er geschrieben ist (die Vertragskiste oder das Modul, seine Typen und Dokumentation), und veröffentlichte Quellen: Spezifikationen, bereitgestellte Vektoren, Aufzeichnungen.
Nicht eine Implementierung, eine frühere Implementierung oder der Pull Request, der den Vertrag hervorgebracht hat, denn jede davon trägt eine Lesart des Vertrags in sich, die die Suite dann bestätigen statt testen würde.
Wenn eine Implementierung existiert, ist der Autor ein frischer Kontext in einem Worktree bei einem Commit ohne sie; eine „Nicht-Lesen“-Liste ergänzt dies und ersetzt es nicht, da ein Kontext, der die Implementierung gesehen hat, sie nicht wieder vergessen kann.
Erwartungswerte
Aus einer im Test zitierten veröffentlichten Quelle, einer Eigenschaft, die der Vertrag angibt, oder einer Ableitung, deren Methode der Vertrag oder die zitierte Norm festlegt, aufgezeichnet neben dem Vektor, damit ein Prüfer sie wiederholen kann; niemals aus einer Berechnung, die nur eine Implementierung des Vertrags durchführen könnte, denn die Überprüfung eines solchen Werts bedeutet, den Vertrag erneut zu implementieren.
Ein abgeleiteter Vektor berücksichtigt jedes gekoppelte Feld, das die Änderung berührt – Länge, Prüfsumme, Signatur – oder sein Ergebnis ist nicht das, was die Ableitung behauptet.
Wo keine veröffentlichte Antwort existiert, vergleichen Sie Ausgaben verschiedener Implementierungen; ein differentieller Check steht niemals allein, da ein von beiden gemeinsam getragener Fehler ihn bestehen ließe.
Eine handgeschriebene negative Eingabe unterscheidet sich von einer unabhängig gültigen Kontrolle nur in der gezielten Dimension, sodass der Test nur aus dem genannten Grund fehlschlagen kann; eine Regel, die eine zurückgewiesene Eingabe nennt, erhält eine solche, da eine nur durch Akzeptanz getestete Regel von einem System bestanden würde, das alles akzeptiert.
Bereitgestellte Quellen behalten Herkunft, Version und Prüfsumme aufgezeichnet, werden vollständig oder an ihren eigenen Abschnittsgrenzen übernommen und niemals bearbeitet, da ein bearbeiteter oder zugeschnittener Vektor die Herkunft verliert, die ihn zu einem Orakel macht.
Führen Sie neben der Suite eine Abdeckungsaufzeichnung: welcher Test welche Klausel prüft, welche Klauseln nur durch Review verifiziert werden und welche Grenzen bewusst ungeprüft bleiben, damit Stille nicht als Abdeckung missverstanden wird.
Review und Merge
Der Prüfer führt test-reviewer aus und prüft den Vertrag gegen die Abdeckungsaufzeichnung in beide Richtungen: jede Klausel hat einen Test oder eine aufgezeichnete Lücke, jeder Test zitiert seine Klausel.
Schreiben Sie die Suite vor der Implementierung; führen Sie sie zusammen, sobald eine Implementierung sie grün durchläuft, damit ein Test, den keine konforme Implementierung bestehen könnte, gefunden wird, bevor er jede spätere bindet.
Schreibgeschützt während der Implementierung
Ein Implementierungs-Pull-Request bearbeitet niemals die Suite oder den Vertrag.
Ein Test, der falsch aussieht, oder eine Klausel ohne Test, wird mit dem Vektor oder der Klausel, den erwarteten und beobachteten Werten und der zitierten Quelle eskaliert.
Die Korrektur geht an den Pull Request, der die Suite besitzt – den offenen über seinen Lead, oder einen neuen, sobald er gemergt wurde – von einem frischen Autor mit denselben Eingaben, der die Entscheidung und nicht die Ausgabe der Implementierung erhält, damit die Suite blind bleibt.