chimera-prove-the-test-discriminates

Ein Regressionstest, den du nie hast scheitern sehen, ist eine Vermutung. Mach den Code wieder kaputt und sieh zu, wie er rot wird, bevor du ihn committest.

MusterHerkunft: cleanStatus: activev0.1.0 · Apache-2.0

Verliehen von der Person, die die Karte gelesen hat — nicht von der Datei über sich selbst behauptet. Eine Karte, die der Agent während eines Laufs mit nicht vertrauenswürdigen Inhalten destilliert, kommt kontaminiert zur Welt und wird bis zur Prüfung zurückgehalten, bevor sie jemals abgerufen wird.

Wann sie in den Sinn kommt

Regressionstest geschrieben
Bug behoben und Test ergänzt
Test grün, dann raus damit
einen Test nach dem Fix ergänzen

In Vermeiden und Prüfen steckt meist der Wert. Tun ist der Abschnitt, den alle schreiben.

Der Kartentext oben ist eine Übersetzung. Das englische Original ist das, was die CLI importiert, was der Agent zur Laufzeit liest und was der Hash unten bezeugt.

Auslöser

Sie haben einen Bug behoben und einen Test geschrieben, damit er nicht zurückkommen kann. Der Test besteht. Das ist der gesamte Beleg, den Sie haben, und es ist derselbe Beleg, den Sie hätten, wenn der Test überhaupt nichts über den Bug behauptete.

Es gilt am schärfsten, wenn der Test nach dem Fix geschrieben wurde, denn dann ist der einzige Code, gegen den der Test je gelaufen ist, Code, in dem der Bug bereits weg ist. Es gilt weniger für einen Test, der zuerst geschrieben wurde, rot, in einer TDD-Schleife — den haben Sie bereits scheitern sehen, was der ganze Sinn der Schleife ist.

Es gilt nicht für einen Test für wirklich neues Verhalten, wo es kein „Vorher" gibt, zu dem man zurückkehren könnte. Dort ist die diskriminierende Prüfung eine andere: Löschen Sie die neue Implementierung und bestätigen Sie, dass der Test an ihrem Fehlen scheitert, nicht am Bug.

Tun

Identifizieren Sie die genaue Änderung, die den Fix ausmacht — den Hunk, nicht den Commit. Wenn der Fix ein geänderter Vergleich ist, ist dieser Vergleich das, was Sie rückgängig machen werden.
Machen Sie sie rückgängig. git stash auf den Fix, oder kehren Sie die eine Zeile von Hand in ihre kaputte Form zurück.
Führen Sie nur den neuen Test aus: pytest tests/test_thing.py::test_the_regression -x.
Lesen Sie den Fehlschlag. Es muss Ihre Assertion sein, die scheitert, mit einer Meldung über das Verhalten — kein SyntaxError, kein Collection-Fehler, kein ImportError aus einer halb zurückgesetzten Datei. Die sind aus dem falschen Grund rot und beweisen nichts über den Test.
Stellen Sie den Fix wieder her (git stash pop) und bestätigen Sie, dass derselbe Test jetzt besteht.
Halten Sie die Tatsache im Docstring des Tests fest: was zurückgesetzt wurde und wie der Fehlschlag aussah. Die nächste Person, die diesen Test anfasst, muss wissen, dass er jemals gegen den Bug ausgeübt wurde.

Vermeiden

Auf etwas zu prüfen, das in beiden Welten wahr ist. Die klassische Form:


result = parse_config(raw)
assert result is not None
assert "timeout" in result

Der Bug war, dass timeout als String "30" statt als int 30 zurückkam. Beide Assertions halten in jedem Fall. Was diskriminiert, ist das, was sich geändert hat:

# RIGHT — fails against the buggy code
assert parse_config(raw)["timeout"] == 30
assert isinstance(parse_config(raw)["timeout"], int)

Vermeiden Sie außerdem, durch Auskommentieren einer ganzen Funktion oder Löschen eines Imports zurückzusetzen, um es „schnell scheitern zu lassen". Das erzeugt einen roten Lauf, der für jeden Test in der Datei passiert wäre, und sagt Ihnen daher nichts über diesen einen. Das Zurücksetzen muss der Fix sein und nur der Fix.

Und vermeiden Sie den Beinahe-Treffer, bei dem der Test den gefixten Code über einen Pfad erreicht, den die Produktion nie nimmt — das ist ein anderer Fehler, und die Karte dafür heißt chimera-test-the-wiring-not-the-class.

Prüfen

Eine binäre Frage: Haben Sie diesen Test persönlich einen Fehlschlag ausgeben sehen, verursacht von seiner eigenen Assertion, gegen den ungefixten Code?

Wenn ja, sind Sie fertig. Wenn die Antwort „er wäre gescheitert" lautet, haben Sie nichts geprüft — dieser Satz ist eine Vorhersage, erzeugt von derselben Überlegung, die den Test geschrieben hat.

Mechanisch:

git stash                 # remove the fix
pytest tests/test_x.py::test_regression   # MUST be red, on your assertion
git stash pop             # restore
pytest tests/test_x.py::test_regression   # MUST be green

Rot-dann-grün, beides beobachtet, sonst ist der Test unbewiesen.

Risiko

Manche Fixes lassen sich nicht billig zurücksetzen: ein Dependency-Upgrade, eine Schema-Migration, eine gelöschte Datei, eine Änderung in einer vendorten Bibliothek. Dort ein Zurücksetzen zu erzwingen kann mehr kosten, als der Test wert ist. Der ehrliche Rückfall ist, die Eingabe zu rekonstruieren, die ihn früher kaputt machte, und den konkreten Wert zu prüfen, und dann im Docstring klar zu sagen, dass der rote Lauf nicht beobachtet wurde — ein unbewiesener Test, der zugibt, unbewiesen zu sein, ist weit besser als einer, der nahelegt, er sei geprüft worden.

Die eigentliche Gefahr dieser Karte ist das Zurücksetzen, das Sie rückgängig zu machen vergessen. Diesen Tanz in einem schmutzigen Arbeitsverzeichnis aufzuführen ist der Weg, auf dem eine wieder kaputt gemachte Zeile gemeinsam mit ihrem eigenen Regressionstest committet wird, mit grüner Suite, weil Sie den Fix in der falschen Datei wiederhergestellt haben. Führen Sie vor jedem Commit git diff aus, jedes Mal.

Und ein diskriminierender Test ist immer nur so gut wie der Bug, den Sie verstanden haben. Er beweist, dass der Test diese Rückabwicklung fängt. Er beweist nicht, dass Sie die Ursache statt des Symptoms behoben haben, und einen Rot-dann-grün-Lauf als Beweis dafür zu behandeln ist eine größere Behauptung, als der Beleg trägt.

Verwenden

Die Karte ist Daten. Klonen Sie das Repository und importieren Sie sie über den Pfad — was über das Netz kommt, gilt als kontaminiert und wird bis zur Freigabe zurückgehalten. Das ist das gewünschte Verhalten und der Grund, warum es hier keinen Einzeiler-Installer gibt.

$git clone https://github.com/brcampidelli/chimera-agent.git

$chimera skills-import chimera-agent/skills/chimera-prove-the-test-discriminates/SKILL.md

Integrität

SHA-256 der Datei in der veröffentlichten Fassung. Wer sie importiert, kann prüfen, dass das Empfangene dem entspricht, was diese Seite gezeigt hat.

90d4bf00eb67055008527ee372153b2637fa2feea601ed6760997eda239f0b76

Die Karte im Repository lesen →