Kostenbewusste Testverifizierung
Reduzieren Sie redundante Arbeit und Ausgabe, ohne erforderliche Prüfungen zu schwächen. Eine bessere Reihenfolge kann Ausführungszeit sparen; eine prägnante Berichterstattung spart Kontext, macht aber keinen bereits laufenden Test schneller. Beanspruchen Sie keine Einsparungen ohne Messungen.
Prüfungen planen und ausführen
- Identifizieren Sie betroffene Komponenten, Risiken, Projektanforderungen und geeignete Prüfungen, bevor Sie teure Suiten ausführen. Befolgen Sie explizite Benutzer- und Projektanforderungen, einschließlich obligatorischer Prüfungen.
- Schließen Sie zuerst die Kernänderung und sinnvolle gezielte Regressionsabdeckung ab. Diagnostizieren und beheben Sie Build- oder Verhaltensfehler mit der engsten relevanten Prüfung. Stabilisieren Sie dann betroffene Integrations- oder End-to-End-Szenarien. Vergleichen Sie bei neuen oder geänderten gemeinsamen Szenarien die Erwartungen mit einer verfügbaren Referenz; überprüfen und dokumentieren Sie absichtliche Unterschiede separat.
- Sobald die Änderung und die gezielten Prüfungen stabil sind, führen Sie die erforderliche finale Suite, statische Prüfungen und Builds nach Bedarf aus. Verwenden Sie ein erfolgreiches Ergebnis nur wieder, solange der relevante Code, die Abhängigkeiten, die Konfiguration, die Umgebung und das Szenario unverändert bleiben.
- Führen Sie nach einer Fehlerbehebung betroffene Prüfungen erneut aus. Wiederholen Sie die breite Suite, wenn die Auswirkungen breit sind, sich Abhängigkeiten ändern, Anforderungen es verlangen oder die Korrektheit unsicher bleibt. Wiederholen Sie nicht automatisch eine vollständige Suite für jeden lokalen Fehler.
- Bewahren Sie bei einem intermittierenden Fehler den ersten Fehler auf und führen Sie den Test allein erneut aus; führen Sie bei Bedarf seine Suite seriell aus, um Störungen zu untersuchen. Melden Sie ungelöste Instabilität, anstatt einen späteren Erfolg als Beweis dafür zu behandeln, dass der Fehler behoben ist.
- Führen Sie bei reinen Dokumentationsänderungen den Diff, relevante Links und Syntaxprüfungen durch; führen Sie Anwendungstests nur aus, wenn erforderlich oder relevant. Halten Sie Leistungsmessungen isoliert von parallelen Builds und Tests, die die Ergebnisse verzerren könnten.
- Fragen Sie langlaufende Jobs in angemessenen Abständen ab, anstatt wiederholt unveränderte Ausgaben zu lesen. Vermeiden Sie es, Arbeiten nur zur Statusprüfung neu zu starten.
Ausgabe nützlich und begrenzt halten
Bevorzugen Sie eine vorhandene Projekt-Runner- oder Framework-Berichtsfunktion. Erfassen Sie vollständige stdout- und stderr in einem eindeutigen, nicht überschreibenden Protokoll, wenn angemessen, und geben Sie eine prägnante Zusammenfassung zurück: Befehlsergebnis und Exit-Status, Dauer, erkennbare Testanzahlen einschließlich übersprungener oder ignorierter Tests sowie Speicherort des Protokolls. Fügen Sie bei Fehlern fehlgeschlagene Fallnamen und einen begrenzten Diagnoseauszug hinzu; überprüfen Sie den relevanten Teil des vollständigen Protokolls, wenn die Zusammenfassung nicht ausreicht. Leiten Sie den Gesamterfolg niemals aus partiellen Suite-Zählungen ab: Verwenden Sie den tatsächlichen Exit-Status des Befehls und geben Sie an, wann eine Zusammenfassung nicht analysiert werden kann. Bewahren Sie Startfehler, Abbruch und Signalverhalten. Stapeln Sie keine redundanten Wrapper um einen vorhandenen Runner.
Testinfrastruktur überprüfen
Wenn Sie einen Test-Runner, Wrapper oder ein Berichtswerkzeug erstellen oder wesentlich ändern, testen Sie die Vertrauenswürdigkeit seiner Ergebnisse. Wählen Sie Fälle basierend darauf, was das Werkzeug tatsächlich tut, und dem Risiko, einen Fehler zu verstecken oder falsch darzustellen. Nützliche Fälle umfassen:
- Ein späterer Fehler nach einer erfolgreichen Suite bleibt ein Fehler, mit dem korrekten Exit-Status.
- Vollständige Ausgabe bleibt erhalten, auch wenn die angezeigten Diagnosen begrenzt sind.
- Übersprünge, Startfehler, nicht erkannte Zusammenfassungen und Unterbrechungen werden korrekt gemeldet oder weitergegeben, wo zutreffend.
Üben Sie beobachtbares Verhalten, einschließlich der Grenze zum zugrunde liegenden Testprozess. Passen Sie die Analyse an das tatsächliche Framework an und vermeiden Sie Tests, die lediglich die Implementierung duplizieren. Dies ist die Verifizierung der Infrastruktur, keine Anforderung, für jeden einzelnen Test Tests zu schreiben. Schreiben Sie ein zuverlässiges vorhandenes Tool nicht um oder testen Sie es nicht erneut, nur weil diese Fähigkeit verwendet wird.
Diagnosetests schreiben
Halten Sie erfolgreiche Tests ruhig, es sei denn, Fortschrittsausgabe ist nützlich. Fehler sollten den Fall, erwartetes und tatsächliches Verhalten, relevante Parameter und jeden zufälligen Seed identifizieren. Beschreiben Sie große Nutzlasten mit Längen, der Position der Abweichung, kurzen Auszügen oder Hashes, anstatt alles auszugeben. Aktivieren Sie bei Bedarf Detailinformationen pro Iteration oder vollständige Ablaufverfolgungen für die Diagnose. Kennzeichnen Sie Übersprünge explizit mit Gründen und wandeln Sie niemals einen Fehler in einen erfolgreichen Exit um. Verbessern Sie vorhandene laute Tests, wenn Sie daran arbeiten, anstatt eine gesunde Suite nur aus Formatierungsgründen neu zu schreiben.