OxideTerm-Test-Audit

Bewahre nützlichen Regressionsschutz auf der Ebene, die das Verhalten besitzt. Verwende die kleinste Überprüfung, die die angeforderte Änderung auflöst; beurteile Ergebnisse anhand der bewahrten Verträge und der erkannten Fehler, nicht anhand von Testanzahlen oder gelöschten Zeilen.

Lies das zutreffende AGENTS.md. Führe Befehle vom Repository-Stammverzeichnis aus. Die Verifikationsmatrix und der Testleitfaden definieren projektspezifische Prüfungen; diese Skill liefert die Entscheidungen zur Testqualität.

Wähle den Umfang

Schreiben oder Ändern eines Tests: Wende die Autorenfragen auf dieses Verhalten an und überprüfe seine nächstgelegene bestehende Abdeckung.
Diagnose eines Fehlers: Stelle fest, warum der Test fehlgeschlagen ist und ob die Implementierung, die Erwartung, das Fixture oder die Umgebung falsch ist, bevor du Änderungen vornimmst.
Audit bestehender Tests: Überprüfe das angeforderte Modul oder Verhalten und dokumentiere Belege für jede vorgeschlagene Änderung. Erweitere auf ein gesamtes Subsystem nur, wenn dieser Umfang angefordert wurde. Verwende denselben Belegstandard für jede Charge.

Die Erstellung oder Verwendung dieser Skill autorisiert keine breite Bereinigung, Subagenten, Commits, Pushes oder Pull-Requests. Beachte die bestehende Autorisierung des Benutzers und etwaige reine Überprüfungsgrenzen. Wenn Änderungen bereits autorisiert sind und die Belege ausreichen, fahre ohne eine weitere Genehmigungsrunde fort.

Autorenfragen

Bevor ein Test hinzugefügt oder geändert wird, identifiziere:

Das beobachtbare Verhalten oder den unabhängigen Vertrag, der geschützt wird.
Eine plausible Regression und die spezifische Behauptung, die sie scheitern lassen würde.
Was die nächstgelegene bestehende Abdeckung übersieht. Erweitere diese Abdeckung, wenn angemessen; eine andere Ebene benötigt ein anderes Integrations-, Protokoll- oder Lebenszyklusrisiko.
Ob der Test einen Produktionsexport, eine Schaltung, einen Wrapper oder einen Injektions-Hook erfordern würde, der keinen Geschäftsanrufer hat. Bevorzuge das Testen an der bestehenden besitzenden Grenze.

Verwende erwartete Werte, die unabhängig von der Implementierung sind. Fixtures müssen das korrekte Verhalten vom wahrscheinlichen Fehler unterscheiden: schließe ausgeschlossene Kandidaten ein, wenn Filter getestet werden, unterschiedliche Sortierschlüssel, wenn Sortierung getestet wird, und tatsächliche sensible Eingaben, wenn Schwärzung überprüft wird. Ein Konstruktorfeld-Hin- und Rückweg, ein nicht leeres Ergebnis oder ein Mock, der das behauptete Verhalten ausführt, ist kein ausreichender Beleg für den beabsichtigten Workflow.

Testhelfer und Fixtures können legitimerweise testexklusiv sein. Die Sorge besteht darin, Produktions-APIs zu verzerren oder veraltetes Produktionsverhalten nur für Tests am Leben zu erhalten.

Diagnostiziere einen fehlgeschlagenen Test

Lies den vollständigen Test, seine Eingaben, den Produktionspfad, die nahegelegene Abdeckung und den relevanten Änderungsverlauf. Identifiziere für CI den fehlgeschlagenen Commit, Job, Testnamen und die Behauptung; ein generischer Exit-Code ungleich null ist keine Ursachenanalyse. Überprüfe die Abhängigkeitsquelle oder -typen, wenn die Behauptung von deren Verhalten abhängt.

Klassifiziere den Fehler anhand der Belege:

Produktionsregression: Der beabsichtigte Vertrag gilt noch. Reproduziere den Fehler und repariere die besitzende Implementierung im autorisierten Umfang.
Veraltete Erwartung: Der Verlauf und der aktuelle Vertrag zeigen eine absichtliche Verhaltensänderung. Aktualisiere das erwartete Verhalten, während der Schutz für unterstützte veröffentlichte Formate und APIs erhalten bleibt.
Fehlerhafter Test oder Fixture: Der Fall übt seine beanspruchte Bedingung nicht aus, verlässt sich auf einen zufälligen Zustand oder schlägt aus einem nicht zusammenhängenden Grund fehl. Repariere das Setup und die Behauptungen an der realen Grenze.
Umgebungsfehler: Kompilierung, Abhängigkeiten, Ressourcen, Plattform oder externe Fixtures verhindern, dass das Verhalten getestet wird. Melde diese Einschränkung; interpretiere sie nicht als bestandenen oder veralteten Test um.

Ein Baseline-Fehler ist kein Grund, einen Test zu löschen. Zeige bei einem Fehlerbehebung den beabsichtigten Fehler vor der Reparatur und den Erfolg danach. Verwende gültige CI-Belege oder eine aufgezeichnete lokale Baseline, wenn sie denselben Fehler nachweist; wiederhole keine teuren Prüfungen nur aus Zeremoniegründen.

Zum Beispiel muss der .oxide-Plugin-Test die validierungsfreie Passwortprüfung von der entschlüsselten Importvorschau unterscheiden. Die Validierungsantwort des verschlüsselten Formats sollte keine Metadaten preisgeben; die passworttragende Vorschau sollte immer noch die explizit erwarteten Beschreibungs- und Verbindungsnamen enthalten. Die Aktualisierung dieser Behauptungen bewahrt den Vertrag, ohne einen weiteren Low-Level-Entschlüsselungstest auf der Plugin-Ebene zu benötigen.

Prüfe vor dem Bearbeiten

Lies jeden Kandidaten vollständig, einschließlich Parameterzeilen. Verfolge seinen Produktionseinstiegspunkt, Aufrufer, relevante Abhängigkeiten, Geschwisterimplementierungen und überlappende Tests. Überprüfe den Verlauf, warum er existiert, und die CI-Routing, welche Prüfungen tatsächlich ausgeführt werden.

Verwende einen kompakten Belegdatensatz für vorgeschlagene Änderungen, in der Arbeitsantwort, sofern kein gespeicherter Bericht angefordert wurde:

Test und Ort	Verhalten und glaubwürdiger Fehler	Entscheidung	Verbleibender oder reparierter Nachweis	Validierung
Exakter Testname und -pfad	Was die Behauptungen erkennen können	Behalten / Reparieren / Konsolidieren / Löschen	Benannter Test oder Grenze, mit relevantem Verlauf	Gezielter Befehl oder manuelles Szenario

Behalten: Es schützt unabhängig einen sinnvollen Vertrag.
Reparieren: Das Verhalten ist wichtig, aber die Eingabe, Behauptung, der Name oder das erwartete Ergebnis ist falsch oder zu schwach.
Konsolidieren: Verschiebe unterschiedliche Behauptungen in den benannten primären Test, bevor du das doppelte Setup oder den doppelten Fall entfernst.
Löschen: Nenne den stärkeren verbleibenden Nachweis oder zeige, dass das Verhalten keinen unterstützten Vertrag mehr hat. Unsicherheit bedeutet untersuchen oder behalten.

Wenn Produktionscode zusammen mit einem Test entfernt wird, identifiziere auch seine Nicht-Test-Aufrufer und erkläre, warum der Code veraltet ist. Suche nach Referenzen, bevor du einen Helfer, Export, eine Funktion oder ein Fixture entfernst. Nimm keine nicht zusammenhängenden Vereinfachungen in das Audit auf.

Muster, die eine Untersuchung wert sind

Der Test wiederholt den Quelltext, die private Aufrufsform oder die genaue interne Darstellung der Implementierung und schlägt nach einer verhaltensbewahrenden Refaktorisierung fehl.
Mehrere Ebenen rufen denselben Helfer mit äquivalenten Eingaben auf und wiederholen seine Behauptungen, ohne ihre eigene Integration zu üben.
Ein Fixture arrangiert die Rückrufreihenfolge, die Abschlussbenachrichtigung oder das persistierte Ergebnis vor, das der tatsächliche Besitzer produzieren sollte.
Ein Verneinungstest wird von der Parametervalidierung zurückgewiesen, bevor er die Berechtigungsprüfung erreicht, die er angeblich testet.
Ein Parallelitäts-, Abbruchs- oder Aufwecktest prüft nur ein finales Flag, ohne die konkurrierende Arbeit oder den Wartenden zu erzeugen.
Eine Erfolgsbehauptung prüft nur Ok, Some, Länge oder Nichtleere, wenn Inhalt, Identität, Reihenfolge oder ein dauerhafter Seiteneffekt der Vertrag ist.

Dies sind Untersuchungssignale, keine automatischen Löschregeln. Bewahre unabhängige Sicherheitsstandards, Protokollbytes, Persistenz- und Migrationsformate, Plugin-APIs, Plattformverhalten, Paketierung, Internationalisierung und Architekturbeschränkungen. Statische Überprüfung kann nützlich sein, wenn sie einen echten Vertrag schützt und irrelevante Umbenennungen überlebt. Langsame Ausführung allein macht einen Test nicht redundant.

OxideTerm-Grenzen

Verhalten	Bevorzugte Verifikationsgrenze
Parsing, Einstellungsnormalisierung, Serialisierung oder Datenzusammenführung	Besitzende Domain-Crate mit expliziten erwarteten Werten und unterstützten Formatbeispielen
SSH-Knotenfreigabe, SFTP, Weiterleitung, Wiederverbindung oder Sprunghosts	Laufzeitbesitzer mit tatsächlicher Consumer-Registrierung, Stornierung und Bereinigung; siehe Laufzeitbesitz
Gemischte Seiten, Fokus, Pop-ups oder späte UI-Ergebnisse	Vorhandener GPUI-Testkontext und Feature-Entität; natives IME-, Fenster- und GPU-Verhalten erfordern weiterhin Host-Validierung
Plugin-, MCP- oder CLI-Adapter	Tatsächlicher Dispatch und zurückgegebene Daten, Autorität, Zielidentität oder Seiteneffekt; vermeide das reine Abspielen des Domain-Helfers
Schwärzung und Anmeldeinformationslebensdauer	Synthetische geheime Eingabe durch die relevante Ausgabe- oder Besitzgrenze; siehe sensible Daten
Paketierung und Repository-Skripte	Vorhandene Skripttests oder der tatsächliche Trockenlaufvertrag, der von der Verifikationsmatrix ausgewählt wurde

Bei einem gemeinsamen Knotentest sollte das Schließen eines Terminals einen anderen tatsächlichen Consumer nutzbar lassen. Bei der Behandlung von veralteten Ergebnissen liefere eine alte Fertigstellung, nachdem der Besitzer gewechselt hat. Verwende vorhandene Fixtures und ereignisgesteuerte Synchronisation; willkürliche Schlaf- und zusätzliche Wiederholungsversuche erzeugen diese Bedingungen nicht.

Validieren und Abschließen

Schließe die relevanten Quell-/Testbearbeitungen ab, bevor du deren Testlauf startest. Halte den Checkout während dieses Laufs stabil.

Führe den fokussierten Test oder das Modul aus, z.B. cargo test -p <crate> <test_filter>. Verwende das Ziel und die Plattform, die es tatsächlich besitzen; die Desktop-Tests befinden sich im oxideterm-native-Binärziel von oxideterm-gpui-app. Der eigenständige Remote-Agent verwendet --manifest-path agent/Cargo.toml.
Lies das Ergebnis und verifiziere, dass die beabsichtigten Tests tatsächlich ausgeführt wurden. Ein erfolgreicher Befehl ohne passende Tests ist kein Nachweis. Nach einer Entfernung oder Verschiebung führe die benannte verbleibende Abdeckung und alle deutlich betroffenen Integrationsprüfungen aus.
Führe cargo fmt --check und git diff --check für Rust-Bearbeitungen aus. Füge Crate-Prüfungen, Skripttests, Locale-Audits oder manuelle Workflows gemäß der Verifikationsmatrix hinzu. Verwende Ergebnisse wieder, bis relevante Änderungen oder neue Belege sie ungültig machen.
Überprüfe das endgültige Diff und den Status. Stelle sicher, dass kein einzigartiges Verhalten verschwunden ist, keine Behauptungen geschwächt wurden, um einen Produktionsfehler zu verbergen, und keine nicht zusammenhängende Arbeit geändert wurde.

Verwende absichtliche Mutation nur, wenn nötig, um einen konkreten Zweifel an einer Behauptung zu lösen. Halte sie isoliert von Benutzerarbeit, stelle die genaue Quelle danach wieder her und erzwinge sie nicht für jeden Test. Subsystemweite Audits sollten die entfernten Fälle gegen ihre benannten verbleibenden Tests abgleichen, bevor die endgültigen betroffenen Suiten ausgeführt werden.

Berichte die Entscheidung, das immer noch geschützte Verhalten, die tatsächlich ausgeführten Prüfungen und jede wesentliche nicht verifizierte Grenze. Erkläre entfernte Abdeckung, wenn eine Löschung stattfand. Stoppe, wenn der angeforderte Umfang abgeschlossen ist; vergrößere das Audit nicht, um eine Zählung oder ein Reduktionsziel zu erreichen.

Quelle

Adaptiert von den Testwert- und Belegprinzipien in OpenClaws test-audit und Kampagnenrichtlinien. Ausführung, Besitz und Validierung folgen hier den Repository-Regeln von OxideTerm.

AnalyseDeCircuit/oxideterm

Was ist oxideterm?

In Ihrer bevorzugten KI fragen

Dokumentation