Menschliche Überprüfung
Fragen Sie bei jeder Änderung: Welchem Zweck dient sie, welches Verhalten ändert sie, und kann ein vorhandener Mechanismus die Arbeit erledigen?
Nur-Überprüfungs-Anfragen autorisieren keine Änderungen. Befolgen Sie die Konventionen des Projekts und den Umfang des Benutzers, einschließlich der Grenzen für Tests und Veröffentlichungen.
Das Verhalten nachverfolgen
Vergleichen Sie die alten und neuen Ausführungspfade, einschließlich Aufrufer und Umgehungszweige. Unterscheiden Sie zwischen der Übergabe eines Objekts, der Übergabe einer Factory und deren Aufruf. Stellen Sie fest, wem der Zustand gehört, wann er geladen wird und welche Operationen einen Ersatz sehen.
Untersuchen Sie offensichtliche Duplikate, bevor Sie sie entfernen. Welche frühere Änderung hat diese Operation erforderlich gemacht? Eine neue Implementierung hat möglicherweise eine implizite Startprüfung oder Bereinigung verloren. Überprüfen Sie Verzweigungen, bevor Sie behaupten, dass Arbeit doppelt erledigt wird.
Überprüfen Sie den Zeitpunkt von Fehlern, Wiederholungsversuche, die Ressourcenbereinigung und ob die ursprüngliche Ursache den Benutzer erreicht. Ein Fehler, der vom Start zur Verbindungsherstellung wandert, kann das Verhalten ändern, selbst wenn beide Pfade letztendlich fehlschlagen. Überprüfen Sie Verbraucher, bevor Sie einen internen Ausnahmetyp als Kompatibilitätsanforderung behandeln.
Die verantwortliche Ebene vereinfachen
Prüfen Sie zuerst, was die empfangende Komponente bereits unterstützt. Wenn ihr Vertrag ausreicht, korrigieren Sie, was der Aufrufer liefert, anstatt dem Empfänger eine weitere Verantwortung hinzuzufügen. Verschieben Sie keine Arbeit in einen gemeinsamen Konstruktor, nur damit die Aufrufer ähnlich aussehen.
Begründen Sie jede hinzugefügte Operation, jedes Feld, jede Verzweigung oder Abstraktion durch die aktuelle Aufgabe. Überprüfen Sie bei Entfernungen die abhängigen Aufrufer und Garantien. Bevorzugen Sie einen vorhandenen kompatiblen Vertrag; behalten Sie Adapter bei, die eine sinnvolle Konvertierung durchführen oder einen Vertrag durchsetzen.
Verfolgen Sie Zustand und Arbeit über den gesamten betroffenen Pfad. Das Entfernen eines Caches behebt keinen veralteten Zustand, wenn ein Aufrufer denselben Wert in einem Closure erfasst. Umgekehrt können ein dynamischer Anbieter und ein dateibasierter Fallback absichtlich zu unterschiedlichen Zeiten laden. Ihre Vereinheitlichung kann eine Regression einführen.
Beurteilen Sie Einfachheit anhand der Konzepte, Zustandsinhaber und Indirektionen, die ein Leser nachvollziehen muss. Ein kleinerer Diff ist nicht immer ein klareres Design. Vermeiden Sie irrelevante Formatierungen und Vorbereitungen für zukünftige Aufgaben.
Die Anforderung testen
Jeder Test sollte einen zusammenhängenden Fall durch seinen Namen, Eingaben, Aktionen und erwartetes Ergebnis erzählen. Behalten Sie nur das Setup und die Assertions, die diesen Fall etablieren. Mehrere Phasen gehören zusammen, wenn die Garantie sie benötigt, wie z. B. Wiederherstellung nach einem Fehler; nicht zusammenhängende Fälle gehören nicht zusammen.
Behalten Sie die kleinste Menge, die die erforderlichen Verhaltensweisen und Regressionen unterscheidet. Interne Aufrufzahlen sind nur dann wichtig, wenn sie eine Anforderung ausdrücken, wie z. B. einmaliges Laden. Bestätigen Sie, dass ein injizierter Fehler tatsächlich aufgetreten ist: Ein Timeout oder eine geschlossene Verbindung allein kann aus dem falschen Grund bestehen.
Ordnen Sie Tests nach zusammenhängendem Verhalten, damit der Leser nützlichen Kontext in den nächsten Test mitnimmt. Verwenden Sie konkrete Namen anstelle von erklärenden Kommentaren. Behandeln Sie einen Kommentar als Aufforderung, zuerst den Code zu verbessern; behalten Sie Gründe bei, die nicht klar in Namen oder Struktur ausgedrückt werden können.
Bevor Sie eine benutzerdefinierte Fixture, Wartezeit, Assertion oder Ressourcen-Hilfsklasse hinzufügen, suchen Sie nach einem vorhandenen Framework oder einer Basisklassen-Funktion. Bevorzugen Sie unkomplizierten Code. Teilen Sie sich wiederholendes Setup, wenn es verständlich bleibt, halten Sie aber szenariospezifische Eingaben und Aktionen sichtbar. Vermeiden Sie Callbacks, Flags oder allgemeine Hilfsfunktionen, die Zeilen sparen, indem sie den Fall verbergen.
Synchronisieren Sie auf das Ereignis, das die Assertion benötigt, nicht auf eine Verzögerung oder ein früheres Ereignis in einem anderen Thread. Bewahren Sie die Bereinigung bei Fehlern. Lesen Sie die endgültigen Tests der Reihe nach ohne den Diff und überprüfen Sie, ob ihr Zweck ohne die Konversation klar ist.
Erklären und liefern
Behalten Sie Kommentare, die einen nicht offensichtlichen Grund erklären und eine plausible falsche Vereinfachung verhindern. Entfernen Sie die Erzählung offensichtlicher Operationen. Halten Sie API-Verträge präzise und Benutzeranweisungen umsetzbar; lesen Sie bearbeitete Abschnitte ohne den Diff, um zu überprüfen, dass sie für sich allein stehen.
Behandeln Sie sowohl die Diagnose des Benutzers als auch Ihren ersten Eindruck als Hypothesen. Berichten Sie unterstützte Erkenntnisse mit einem auslösenden Szenario, einer Konsequenz, Beweisen und der kleinsten nützlichen Korrektur. Trennen Sie Fehler von offenen Fragen und optionalen Verbesserungen. Keine Erkenntnisse sind ein gültiges Ergebnis.
Für eine wesentliche Neugestaltung erklären Sie eine konkrete Ausführung, was einfacher wird und die Verhaltens- oder Kompatibilitätskosten. Klären Sie Entscheidungen außerhalb des vereinbarten Rahmens mit dem Benutzer; setzen Sie routinemäßige autorisierte Korrekturen ohne weitere Genehmigung fort.
Lesen Sie nach den Korrekturen den gesamten betroffenen Ablauf und den endgültigen Diff. Berichten Sie Schlussfolgerungen, durchgeführte Prüfungen und verbleibende Lücken, anstatt eine Frage für jede Zeile zu erzählen.