Beweise es (Prove It)
Etablieren Sie eine enge Behauptung: Derselbe Test erfasst das spezifizierte fehlerhafte Verhalten vor einer Reparatur und besteht danach. Eine bestandene Testsuite allein etabliert dies nicht.
Wählen Sie den Zeugen
Überprüfen Sie den Fix und den relevanten Test. Identifizieren Sie die erwartete Eingabe/Ausgabe oder den Zustandsübergang und wählen Sie genau einen pytest-Node aus. Verwenden Sie zwei committete lokale Git-Referenzen; die Nach-Referenz muss sowohl den Fix als auch den Test enthalten. Nicht committete Änderungen werden nicht einbezogen. Committen Sie nicht die Arbeit anderer, nur um dieses Tool auszuführen.
Die Fehlerbehauptung benötigt eine spezifische Nachricht, wie z. B.:
assert expired(now=10, deadline=10), "PROVEIT:expiry-boundary"
Die Nachricht muss in einer Assertion in der ausgewählten Testfunktion stehen. Platzieren Sie sie nicht in nicht zugehörigen Assertions, in einem Fixture, im Anwendungscode oder in einer print-Anweisung. Überprüfen Sie, dass diese Assertion tatsächlich das vom Fehler beschriebene Verhalten beobachtet. Wenn der vorhandene Test eine Nachricht benötigt, fügen Sie sie nur innerhalb des autorisierten Bearbeitungsbereichs hinzu und schließen Sie diesen Test in die Nach-Revision ein. Andernfalls erklären Sie die fehlende Eingabe.
Führen Sie den Vergleich aus
Führen Sie das gebündelte Skript über seinen absoluten Installationspfad aus. Der ausgewählte Interpreter benötigt pytest und die Abhängigkeiten des Projekts, die bereits installiert sein müssen. Es wird keine Abhängigkeitsinstallation, Netzwerkzugriff, Git-Checkout, Reset, Stash oder Commit durchgeführt.
python <skill-directory>/scripts/proveit.py --repo <repository> --before <old-ref> --after <fixed-ref> --test tests/test_expiry.py::test_at_deadline --expect PROVEIT:expiry-boundary --output <new-directory-outside-repository>
Der Runner überlagert die ausgewählte Testdatei der Nach-Revision auf beiden Snapshots, verwendet eine frische Kopie pro Versuch und standardmäßig drei Durchläufe pro Revision mit einem Timeout von 10 Sekunden pro Durchlauf. Verwenden Sie --python, --repeat 2..5 oder --timeout nur, wenn es die Aufgabe erfordert. Wählen Sie eine vollständige Parameter-ID, wenn der Test parametrisiert ist.
Snapshots isolieren Dateien, nicht die Ausführung. Führen Sie nur Code aus, dessen Ausführung in dieser Umgebung bereits autorisiert ist. Tests behalten den Zugriff auf das Dateisystem, das Netzwerk und die Anmeldedaten des Benutzers. Interpretieren Sie ein temporäres Verzeichnis nicht als Sicherheitssandkasten. Bereinigen Sie niemals nicht zugehörige Worktrees oder Verzeichnisse. Der Runner entfernt nur seine eigenen temporären Snapshots und hinterlässt das Beweisverzeichnis zur Überprüfung.
Überprüfen Sie die Beweise
Lesen Sie report.md, report.json, selected-test.py, fix.diff und die relevanten Logs. Überprüfen Sie die beobachtete Assertion, den ausgewählten Node, die Phasenaufzeichnungen und die geänderten Pfade.
| Ergebnis | Interpretation | Exit-Code |
|---|---|---|
supported | Jeder alte Durchlauf trifft die deklarierte Assertion; jeder neue Durchlauf besteht. | 0 |
not_supported | Der alte Test besteht ebenfalls, oder die reparierte Revision trifft immer noch diese Assertion. | 1 |
inconclusive | Umgebung, nicht zugehöriger Fehler, Timeout, Überspringen, unvollständige oder instabile Ausführung. | 2 |
Ein nicht zugehöriger Aufruffehler ist selbst dann nicht eindeutig, wenn die neue Revision besteht. Sammlungs-, Abhängigkeits-, Syntax-, Setup- und Teardown-Fehler sind niemals ein Zeuge. Bezeichnen Sie sie nicht als erkannten Fehler. Beheben Sie die beobachtete Ursache innerhalb des Umfangs und führen Sie das Tool erneut in ein neues Beweisverzeichnis aus; wiederholen Sie keinen unveränderten fehlgeschlagenen Setup.
Bevor Sie supported akzeptieren, überprüfen Sie die revisionsspezifischen Fixtures/Konfigurationen und bestätigen Sie, dass sie die Änderung nicht erklären. Nur die ausgewählte Testdatei wird überlagert. Installierte Abhängigkeiten werden gemeinsam genutzt, das automatische Laden von Drittanbieter-pytest-Plugins ist deaktiviert und das Projekt-addopts wird gelöscht. Projekte, die externe Plugins oder Builds benötigen, benötigen möglicherweise eine separat vorbereitete Umgebung; geben Sie eine nicht unterstützte Ausführung direkt an.
Berichten Sie den Test, die Referenzen, das Ergebnis, den Speicherort der Beweise und die wesentlichen Einschränkungen. Sagen Sie, dass dieser Zeuge das spezifizierte Verhalten in diesen Durchläufen erfasst hat. Behaupten Sie keinen Beweis für allgemeine Korrektheit, Abwesenheit von Flakiness, allgemeine Testqualität oder gemessene Produktivitätsverbesserung. Veröffentlichen Sie keine Berichte, die lokale Pfade oder Logs enthalten, ohne diese zu überprüfen und die entsprechende Veröffentlichungsgenehmigung einzuholen.