chimera-write-the-check-before-the-code
Ein Kriterium, das nach der Implementierung geschrieben wird, beschreibt die Implementierung. Schreibe zuerst die fehlschlagende Prüfung, sieh sie scheitern, dann baue.
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
- gleich ein Feature umsetzen
- definieren, was fertig heißt
- den Test nach dem Code schreiben
- keine Abnahmekriterien an der Aufgabe
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 sind dabei, etwas zu implementieren, dessen „fertig" noch nicht beobachtbar ist — ein Feature, eine Fehlerbehebung, ein Refactoring, das Verhalten zu erhalten behauptet. Es beißt am härtesten, wenn Autor und einziger Reviewer derselbe Prozess sind: ein Agent, der allein arbeitet, oder ein Solo-Commit, den niemand sonst lesen wird.
Das gilt nicht für einen Spike. Exploration, deren Zweck es ist, herauszufinden, was überhaupt möglich ist, hat noch kein Abnahmekriterium, und eines vorab zu erfinden verankert Sie nur an der ersten Idee. Schreiben Sie die Prüfung, wenn der Spike endet und die eigentliche Arbeit beginnt.
Diese Karte handelt von der Prüfung, die es noch nicht gibt. Ihr Gegenstück,
chimera-prove-the-test-discriminates, handelt von einer Prüfung, die bereits existiert und leer
sein könnte — zu der greifen Sie nach einem Fix, um zu zeigen, dass der Test ohne ihn scheitert.
Derselbe Instinkt, entgegengesetzte Enden der Arbeit.
Tun
- Schreiben Sie das Kriterium, bevor Sie die Implementierung anfassen, als etwas, das scheitern kann: einen Test, eine Assertion, einen Befehl, dessen Exit-Code umschlägt, eine Query mit einer erwarteten Zeile. Prosa ist keine Prüfung — „der Endpunkt sollte schneller sein" ist keine; „p95 unter 200 ms auf dem Fixture-Set, gemessen mit dem bestehenden Bench-Befehl" ist eine.
- Sagen Sie, woher die Beobachtung kommt. Von der Maschine, nicht von Ihrer Lesart des Diffs.
- Führen Sie die Prüfung jetzt aus, gegen unveränderten Code. Sie muss scheitern. Besteht sie, existiert entweder das Verhalten bereits — dann hören Sie auf, es gibt nichts zu bauen — oder die Prüfung testet nicht, was Sie glauben.
- Lesen Sie die Fehlermeldung. Sie muss aus dem beabsichtigten Grund scheitern, nicht an einem Import-Fehler, einer fehlenden Fixture oder einem Tippfehler im Testnamen. Ein Rot aus der falschen Ursache ist ein verkleidetes Grün.
- Bringen Sie die Prüfung vor der Implementierung ein, in einem eigenen Commit. Sobald die Implementierung existiert, wird die Prüfung an sie anpassbar, und sie wird angepasst werden.
- Implementieren Sie. Fertig ist, wenn die Prüfung besteht — nicht, wenn der Code fertig aussieht.
Vermeiden
Die Assertion hinterher zu schreiben, aus der Ausgabe:
normalize(" Foo ") # -> "foo"
# test transcribed from that observation
assert normalize(" Foo ") == "foo"
Diese Assertion kann gegen den Code, aus dem sie kopiert wurde, nicht scheitern. Sie hält Verhalten
fest statt Anforderung, bleibt also durch jeden Bug hindurch grün, über den die Implementierung
intern konsistent ist. Wenn die Anforderung NFKC-Normalisierung war und Sie strip().lower()
ausgeliefert haben, stimmt Ihnen dieser Test für immer zu.
Vermeiden Sie außerdem das Kriterium, das eine Umformulierung der Änderung ist — „fertig, wenn die Funktion hinzugefügt ist", „fertig, wenn die Migration läuft". Beide sind durch einen leeren Rumpf erfüllt.
Prüfen
Zwei binäre Fragen, beide aus dem Repository beantwortbar:
- Haben Sie die Prüfung scheitern sehen, bevor die Implementierung existierte? Wenn es keinen Moment gibt, in dem sie rot war, haben Sie keinen Beleg, dass sie rot werden kann.
- Wäre die Prüfung noch korrekt, wenn das Feature auf eine völlig andere Weise gebaut worden wäre? Eine Prüfung, die Interna benennt — einen privaten Aufruf, eine Log-Zeile, einen exakten SQL-String —, ist an Ihre Lösung gepinnt statt an die Anforderung und wird das nächste Refactoring blockieren, ohne etwas zu fangen.
Konkret: git log zeigt die Prüfung zeitgleich mit oder vor der Implementierung landen, und nur den
Implementierungs-Commit zurückzunehmen macht die Suite rot.
Risiko
Eine Anforderung, die Sie noch nicht verstehen, lässt sich nicht durch eine zuerst geschriebene Prüfung festnageln. Sie werden eine präzise Assertion über das Falsche schreiben und dann darauf hin implementieren — schlimmer, als keine Prüfung zu haben, weil es ein Missverständnis in eine grüne Suite wäscht, der ein Reviewer vertrauen wird. Wenn das Kriterium wirklich unbekannt ist, ist das ein Signal, nachzufragen, eine Frage nach der anderen, nicht in Testform zu raten.
Es gibt außerdem schlichte Kosten. Für eine Tippfehlerkorrektur oder eine Doku-Änderung ist die Prüfung zuerst zu schreiben Zeremonie, die niemand bezahlt. Die Karte verdient ihren Platz, wenn das Verhalten tragend genug ist, dass jemand darunter leidet, wenn „fertig" falsch ist.
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.gitchimera skills-import chimera-agent/skills/chimera-write-the-check-before-the-code/SKILL.mdIntegritä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.
95d0a1b750e25af7651e85d26106a91f02f563ab1a1422edc4133d16942b67d7