Name: svk1998/test-audit
Author: Community-Skills

Test Audit

Diese Fähigkeit hat zwei Modi:

Autoring. Der unten stehende Autoren-Gate gilt für jeden Test, den Sie hinzufügen oder ändern.
Auditieren. Entfernen Sie minderwertige Nachweise in kohärenten Batches, gruppiert nach Produktionseigentümer. Jagen Sie niemals Löschzahlen; das Ziel ist eine Suite, in der jeder Vertrag einen starken Eigentümer hat, nicht eine kleinere Anzahl.

Für eine Kampagne, die die gesamte Testoberfläche eines Subsystems auf einmal bereinigt, lesen Sie zuerst CAMPAIGN.md.

Autoren-Gate

Bevor Sie einen Test hinzufügen, beantworten Sie diese vier Fragen:

Welches beobachtbare Verhalten, Invariante oder unabhängigen Vertrag schützt er?
Welche glaubwürdige Regression würde ihn zum Scheitern bringen?
Warum verfehlt der vorhandene Nachweis dies? Jeder Vertrag sollte einen primären Eigentümer an der stärksten Grenze haben. Ein Test auf einer anderen Ebene benötigt ein eigenes Transport- oder Lebenszyklusrisiko, um ihn zu rechtfertigen. Erweitern Sie vorhandene Tabellen und gemeinsame Fixtures anstatt fast identische Kopien hinzuzufügen, und konsolidieren Sie wiederholte Einrichtungen.
Benötigt er einen Export, ein Flag, einen Wrapper oder einen Injektions-Hook, der keinen Produktionsaufrufer hat? Verschieben Sie in diesem Fall den Nachweis an die echte Grenze.

Unterstützende Regeln:

Verwenden Sie den Grenz- und Kostenleitfaden, um zu wählen, wo der Test lebt und was er kosten darf.
Ein Regressionstest muss vor dem Fix für den beabsichtigten Grund fehlschlagen und nach der Reparatur bestehen. Wenn Sie den Fehler vor dem Fix nicht zeigen können, geben Sie dies in Ihrem Bericht an.
Eine Regression an der eigentumsrechtlichen Grenze deckt einen Fehler ab. Wiederholen Sie ihn niemals auf jeder Ebene, die der Fehler durchquert hat.
Ein verhaltensbewahrendes Refactoring sollte den Test nicht brechen.

Lehnen Sie Selbstvergleiche, kopierte Inventare, Quelltext-Durchsuchungen, Implementierungs- oder Aufrufstruktur-Assertions, doppelte Verträge, test-only Seams, erwartete Werte, die vom zu testenden Subjekt generiert wurden, und Mocks, die das zu assertierende Verhalten liefern, ab.
Fixtures dürfen keine Quittungen oder Ordnungen erfinden, die der Eigentümer produzieren sollte, und dürfen keine Persistenz durch einen Pfad behaupten, den der Code nie schreibt.
Eine Negativkontrolle muss an der beabsichtigten Absicherung fehlschlagen, und der Name eines Tests muss mit dem tatsächlich ausgeübten Verhalten übereinstimmen.
Verwenden Sie bei der Prüfung von Kandidaten die vollständige Checkliste.

Behalten Sie Tests, die unabhängige Verträge schützen: öffentliche API, SDK, Protokoll, Konfiguration, Migration, Speicher, Sicherheit, Plattform, Voreinstellungen, Prompt-Bytes, generierte sprachübergreifende Ausgabe, Paketierung, Release, Architektur und beobachtbare Ordnung. Statisch oder langsam zu sein macht einen Test nicht entsorgbar.
Quelltext-Inspektion ist nur akzeptabel, wenn sie Refactorings überlebt, die nur Bezeichner betreffen, und einen unabhängigen benutzerseitigen Vertrag schützt.
Ein fehlschlagender Basistest kann ein Produktfehler sein, der repariert werden muss, kein Test, der gelöscht werden soll.

Lesen Sie vor jedem Audit-Eingriff die Kandidatenevidenz und den Workflow. Überprüfen Sie die vollständigen Eigentümer, Aufrufer und die Historie und zeichnen Sie auf, welcher Nachweis erhalten bleibt, bevor Sie etwas löschen.
Löschen Sie veraltete Produktions-Seams zusammen mit ihren Tests. Optimieren Sie niemals auf Löschzahlen.
Bearbeiten Sie den Checkout nicht, während ein Testlauf läuft. Führen Sie den fokussierten Testbefehl des Projekts für den Eigentümer und die Geschwistertests aus, führen Sie die Checks des Projekts für geänderte Dateien aus und holen Sie dann eine Überprüfung ein, bevor Sie landen.
Berichten Sie die Ursachen, die erhaltenen Verträge, den Nachweis und seine Kosten, die geänderten Produktions- versus Testzeilen sowie Folgemaßnahmen. Committen, pushen oder landen Sie nur, wenn die Aufgabe Ihnen diese Autorität gibt.