Verbessere ein Mutationstest-Tool anhand des aktuellen Codes und der Tests

## Prüfe vor jeder Änderung den aktuellen Code, die Tests und Designnotizen Behandle den aktuellen Quellbaum, die Tests, Schemata, Architekturentscheidungen und die Dokumentation für Mitwirkende als Spezifikation. Vertraue weder Erinnerungen noch alten Annahmen oder allgemeinen Systemmustern, wenn sie den Nachweisen im Codebestand widersprechen. Gehe bei jeder Funktion oder Fehlerbehebung so vor: 1. Durchsuche die nächstgelegenen Unit-, Integrations-, End-to-End-, Architektur- und Selbstmutationstests umfassend, auch nach verwandten Namen, Fehlern, ungültigen Eingaben und Grenzfällen. 2. Lies die zuständige Implementierung, um Reihenfolge, Standardwerte, Fehlersemantik und Leistungsgrenzen zu verstehen. 3. Lies referenzierte Entwurfsentscheidungen und vorgelagerte Diskussionen, wenn die Absicht aus dem Code nicht hervorgeht. 4. Schreibe oder übernimm vor der Implementierung einen gezielten fehlschlagenden Fall und verknüpfe ihn mit seinem Nachweis. 5. Dokumentiere die Gründe für nicht offensichtliche Mechanismen, Versionsgrenzen und beabsichtigte Inkompatibilitäten. Verwende das Projektglossar einheitlich. Betrachte eine Mutation als serialisierbare Änderungsbeschreibung, die in einem anderen Prozess angewendet werden kann, und einen Mutator als getrennte Eignungsprüfung mit anschließender Transformation. Erfasse vor einer Änderung die Ausführungskette: Konfiguration, Quell- und Abdeckungserfassung, AST-Anreicherung, Mutationserzeugung, Mutantenausführung, optionale Folgeanalyse und Berichterstellung sind geordnete Verantwortungsgrenzen. Wenn eine Änderung einen dokumentierten Pfad, eine Prüfschranke oder eine Konvention ungültig macht, aktualisiere die Dokumentation in derselben Änderung. ## Halte die Regeln für öffentliche API, Typen und Benennung ein - Produktionscode darf nicht von Tests oder Leistungsmessungen abhängen. Lege mitgelieferte Testhilfen in einen ausdrücklich produktionsseitigen Testnamensraum und erzwinge die Abhängigkeitsrichtung mechanisch. - Behandle die öffentliche API als Positivliste. Kennzeichne alles andere als intern, dokumentiere Erweiterungspunkte und ordne jede Änderung der Positivliste als Kompatibilitätsereignis ein. - Verwende ein hartes `final` nur für Klassen, die niemals durch Testdoubles ersetzt werden. Halte ersetzbare Dienste technisch überschreibbar, ohne nur für ein Testdouble einer einzelnen Klasse eine Schnittstelle hinzuzufügen. - Importiere Funktionen und Konstanten einheitlich. Wähle bei Aufrufen, die `false` zurückgeben können, eine ausdrückliche Fehlersemantik: Verwende bei außergewöhnlichem Fehlschlag eine sichere Hülle und bei benötigter false-Rückgabe einen klar benannten unsicheren Alias. - Bevorzuge typisierte Konstanten, ausdrückliche Überschreibungsmarkierungen und unveränderliche Wertobjekte. Deklariere eine Klasse nicht als `readonly`, wenn sie Ergebnisse in eigenen Eigenschaften memoisiert. - Verwende Laufzeitzusicherungen nur für Invarianten, die die statische Analyse nicht beweisen kann. Die Meldung muss den Fehler benennen, auf den ein Scheitern hinweist. - Drücke Verträge durch Namen aus: `find*` liefert einen nullfähigen Wert, `get*` garantiert einen Wert, benannte Konstruktoren vermitteln Domänenbedeutung und Ausnahmen beschreiben den Domänenfehler, statt nur allgemein auf `Exception` zu enden. - Reserviere `Memoized*` für unsichtbare Wiederverwendung einmal je Instanz. Verwende `Cached*` nur, wenn Aufrufende Schlüssel, Ungültigmachung, TTL oder ein gemeinsam genutztes Speichersystem beobachten können. - Mache rein statische oder ausschließlich aus Konstanten bestehende Klassen nicht instanziierbar. Nutze Abhängigkeitsinjektion nur für zustandsbehaftete oder E/A-ausführende Beteiligte. - Halte übernommenen vorgelagerten Code erkennbar, bewahre seine Herkunftsangabe und dokumentiere jede beabsichtigte lokale Abweichung. ## Bewahre verzögerte Auswertung und übergib Unterprozess-Befehle als Argument-Arrays - Stelle teure wiederverwendbare Werte durch eine memoisiert verzögerte Abstraktion dar. Ein unverpackter Generator lässt sich nur einmal durchlaufen und darf nicht zurückgesetzt, gezählt oder zwischengespeichert werden. - Unterscheide eine strikte Eins-zu-eins-Abbildung von einer entfaltenden Eins-zu-viele-Abbildung. Ähnliche Methodennamen dürfen unterschiedliche Stromkardinalitäten nicht verdecken. - Erlaube Änderungen per Referenz in einem gemessenen leistungskritischen Pfad nur, wenn Eigentum und direkte Wirkung dokumentiert sind. - Injiziere Zeitgeber- und Dateisystemabstraktionen, statt Zeit- oder Datenträgerprimitive direkt aufzurufen. Tests müssen Zeit- und Dateisystemergebnisse steuern können. - Stelle Unterprozessbefehle durchgehend als Felder aus Zeichenkettenargumenten dar. Ein Feldelement entspricht genau einem Argument; verbinde niemals vorab einen Shell-Befehl und unterstelle keine Aufteilung an Leerzeichen. - Pflege genau ein ausdrückliches Diensteregister mit typisierten Zugriffsmethoden und verzögert initialisierten Fabriken. Verbraucher dürfen keine untypisierte Dienstsuche verwenden; spekulative, unerreichbare Dienste sind verboten. - Binde die Konfiguration durch Klonen des Containers neu, statt gemeinsam genutzten Prozesszustand zu verändern. Extrahiere eine typisierte Erzeugerklasse, wenn eine Verdrahtungsfunktion komplex wird. - Führe Konfiguration entsprechend der Semantik jedes Feldes zusammen: Nullfähige Überschreibungen verwenden Null-Koaleszenz, während von beiden Quellen erzwingbare Schalter ein logisches ODER verwenden. Eine Vereinheitlichung verändert das Verhalten unbemerkt. - Löse relative Ausgabepfade am Speicherort der Konfigurationsdatei auf, erhalte ausdrücklich erlaubte Datenstrompfade und berechne eine Versionsverwaltungsbasis, damit nur die beabsichtigten Änderungen der Benutzer verarbeitet werden. ## Halte die AST-Verarbeitungsreihenfolge ein und lass den ursprünglichen Baum unverändert - Behandle die Registrierungsreihenfolge der Besucherkomponenten als Teil des Algorithmus. Löse Namen und Eltern vor ihren Verbrauchern auf, wende Ausschlüsse vor dem Anhängen von Tests an und setze wiederverwendbaren Besucherzustand vor jeder Datei zurück. - Übermittle Informationen über typisierte Zugriffsmethoden für Knotenattribute. Ein Ausschluss kennzeichnet einen Knoten als ungeeignet; während der Anreicherung entfernt oder ersetzt er niemals Knoten. - Hänge teure Abdeckungsabfragen verzögert und nur an geeignete Knoten. Bewahre die zwei Verzögerungsebenen zwischen dem Finden von Abdeckungsdateien und dem dateiweisen Einlesen von Teststellen. - Leite XML-Abfragen durch eine sichere, namensraumbewusste Hülle. Bewahre geordnete Formatausweichfolgen samt Versionsbegründung; Aufräumarbeiten dürfen keinen noch unterstützten Zweig entfernen. - Halte die Prozessausführung stromförmig. Kennungen von Arbeitsprozessen, die Benutzertests verwenden, sind genaue, bei 1 beginnende API-Werte. Folgeanalysen gehören in die Prozesscontainerkette, nicht in planerabhängige Verzweigungen. - Bewahre die Einheitensemantik in Planungsberechnungen: Die zum Einreihen von Arbeit benötigte Zeit ist eine Dauer, keine Anzahl. Gib Referenzen auf abgeschlossene Container frei, bevor Arbeitsprozessplätze wiederverwendet werden. - Halte versionsabhängige Änderungen der Testausführungskonfiguration getrennt und kombinierbar. Bewahre maßgebliche moderne Abdeckungseinstellungen, benutzerdefinierte Einschlussfilter, musterfähige Pfade und ältere Dokumentformen. - Gleiche ein Mutationsziel anhand der Positionen lexikalischer Einheiten und der Knotenklasse ab. Klone den ursprünglichen AST vor der Mutation, bewahre die ursprünglichen lexikalischen Einheiten für formaterhaltende Ausgabe und halte den ursprünglichen Baum bytegenau identisch. - Behandle Mutationshashes, Feldreihenfolge und erforderliche Positionsattribute als öffentliche Wiederholungsverträge. Kopiere beim Neuaufbau von Knoten jedes Kind und Attribut; ein gültiger Ersatz kann ein Skalarwert, ein Knoten oder eine Knotenliste sein. ## Baue Mutatoren, die keine ungültigen oder gleichwertigen Mutanten erzeugen Eine vollständige Mutatoränderung aktualisiert die Implementierung, alle zentralen Register und Profilzuordnungen, das Konfigurationsschema, einen kanonischen Test sowie bei öffentlichem Verhalten die Benutzerdokumentation. - Halte die öffentliche Mutatoroberfläche klein: Definition, stabiler Name, Eignung und Transformation sowie Konfigurationszugriff nur bei konfigurierbaren Mutatoren. - Die Definition muss Mutation, Kategorie, einen beispielhaften Änderungsvergleich und das Abtöten des Mutanten durch Benutzer erklären. - Vergleiche Sprachbezeichner in Eignungsprüfungen nach den tatsächlichen Regeln für Groß- und Kleinschreibung und durchlaufe Vorgängerknoten, wenn verschachtelter Kontext wichtig ist. - Erzeuge niemals Syntaxfehler, garantiert fatale Fehler, gleichwertige Mutationen, Endlosschleifen oder eine Mutation, für die bereits ein anderer Mutator zuständig ist. - Begründe mögliche Überschneidungen oder Gleichwertigkeit und füge einen benannten Fall ohne Mutation hinzu. - Kopiere beim Erstellen eines Ersatzknotens im AST alle Kinder und Metadaten, damit Attribute nicht unbemerkt verloren gehen. - Führe Mutatoren mit dem produktiven Traversierungsprüfgerüst aus. Erstelle keine einmalige Traversierung, die Eignungs- oder Geltungsbereichsverhalten umgeht. - Behandle eine fehlende erwartete Ausgabe als ausdrückliche Zusicherung, dass keine Mutation erfolgt, und formuliere Datensatznamen wie Spezifikationen. - Melde je Mutator die Anzahl der erzeugten, abgetöteten, entkommenen und durch Zeitüberschreitung beendeten Mutanten, wenn sich das Mutationsvolumen ändert. ## Schreibe wiederholbare Tests, die Mutanten erkennen - Gib jeder konkreten Quellklasse einen kanonischen Test und jedem Test ein ausdrückliches Abdeckungsziel. - Ordne Tests mit E/A den Integrationstests und Tests ohne E/A den Nicht-Integrationstests zu. Erzwinge die Grenze in beide Richtungen. - Halte Tests deterministisch: Verwende erzeugte temporäre Pfade, fixiere die Parallelität für ausgabereihenfolgeabhängige Prüfdaten, sichere Umgebungsvariablen und vermeide fest eingetragene nicht vorhandene Pfade. - Verwende statische Datenlieferanten mit beschreibenden Fallnamen. Bevorzuge benannte Argumente und Standardwerte für breite Testsignaturen, aber teile keinen Lieferanten zwischen Tests, die unterschiedliche Teilmengen verwenden. - Ersetze tiefe Geflechte aus Testdoubles durch kleine unveränderliche Erzeuger oder Fälschungen. Prüfe in den Erwartungen an Testdoubles genaue Argumente, damit Mutationen nicht durch lockere Zusicherungen entkommen. - Strukturiere Produktionscode so, dass Mutationen sichtbar werden: Bevorzuge frühe Rückgaben, getrennte boolesche Ergebnisse und benannte Konstanten gegenüber nicht prüfbaren magischen Literalen. - Vermeide Standardargumente in Konstruktoren, die fehlende Abhängigkeiten verbergen. Standardwerte in Datenlieferanten sind zulässig, wenn jeder Fall dadurch nur seine Abweichung angibt. - Verwende die Besucher-, Befehls- und weiteren produktionsnahen Prüfgerüste des Projekts. Schreibe kein Wegwerf-Prüfskript, wenn stattdessen ein gezielter Unittest bestehen sollte. - Ein entkommener Mutant weist auf einen fehlenden Test oder auf umzuformenden Code hin. Besprich tatsächlich nicht abtötbare oder rein leistungsbezogene Fälle, statt einen gekünstelten Test zu schreiben. - Führe während der Iteration gezielte Tests aus. Führe vor der Übergabe das Formatierungswerkzeug, die Architektur- und statische Analyseprüfung, relevante Integrationsgruppen und die maßgebliche vollständige Testsuite aus. ## Behalte versionsabhängige Einstellungen und Ausweichregeln beim Aufräumen des Codes bei - Dokumentiere Versionsgrenzen und Ausweichstufen zusammen mit dem geschützten Verhalten. Vereinfache eine Kompatibilitätsmatrix nicht nur deshalb, weil allein die neueste Form vertraut ist. - Verarbeite Schlüssel in geordneten Konfigurationsminisprachen nacheinander und lass spätere Einträge gewinnen. Ein false-Wächter muss alles entfernen, was der Schlüssel registriert hat, einschließlich verschachtelter Profile. - Bewahre Zusammenführungsrichtung und ausdrückliche Dublettenbereinigung. Eine Befehlszeilenauswahl darf die Dateiauswahl ersetzen und muss dabei globale Ausschlussregeln erhalten. - Mache ein Register zur maßgeblichen Quelle für alle unterstützten Mutatoren und leite daraus automatische Abdeckungsprüfungen ab. - Nähert sich ein Testnamenfilter der Grenze regulärer Ausdrücke, lockere ihn von genauer Filterung zu einer sicheren Obermenge und lass ihn schließlich weg, damit die vollständige Testsuite läuft. Gehe niemals zu einer Ausführung ohne Tests über. - Bewahre die gekoppelte Regel, nach der das Ergebnis „Keine Tests ausgeführt“ bei gültiger leerer Auswahl als bestanden gilt. - Leite die Fähigkeit nach einem Neustart ohne Debugger nicht von der aktuell geladenen Erweiterung ab. Frage die Neustartsteuerung, welche Version übersprungen wurde, und aktiviere Abdeckung nur im benötigten Kindprozess. - Wende Anpassungen der Speichergrenze erst nach der statischen Analyse und nur auf die temporäre Kindprozesskonfiguration an; führe sie bestmöglich mit ausdrücklichen Schutzbedingungen aus. - Miss prozessintensive Optimierungen, bevor du sie beibehältst. Prüfe alte Leistungsumgehungen erneut, wenn sich Laufzeit- oder Werkzeugkettenversionen ändern. ## Schütze die Lockfile und führe nur Pull Requests mit bestandener CI zusammen Umgehe bei einer unbeaufsichtigten Installation niemals eine festgeschriebene Abhängigkeitsdatei. Erfordert die Auflösung von Abhängigkeiten eine Änderung dieser Datei, halte an und hole eine ausdrückliche Genehmigung ein. Genaue Versionen, Integritätshashes und Lizenzverträglichkeit sind Grenzen der Lieferkette. Übertrage niemals direkt auf einen geschützten Standardzweig, umgehe dessen Schutz nicht und erzwinge keine administrative Zusammenführung. Verwende diese Reihenfolge: 1. Erstelle einen fokussierten Funktionszweig. 2. Nimm die kleinste zusammenhängende Änderung vor und führe gezielte Prüfungen aus. 3. Checke die Änderung gemäß der vorgeschriebenen Nachrichtenkonvention des Codebestands ein. 4. Übertrage den Zweig und öffne eine Änderungsanfrage. 5. Warte auf alle erforderlichen Formatierungs-, Typ-, Unit-, Integrations- und End-to-End-Prüfungen. 6. Behebe Fehler, statt sie zu umgehen. 7. Führe über die genehmigte Methode zusammen und lösche den Zweig. Vermische Refaktorierungen nicht mit Verhaltensänderungen. Behobene Fehler erfordern Regressionstests, Kompatibilitätsbrüche ausdrückliche Veröffentlichungshinweise und Migrationsanleitungen, und benutzersichtbares Verhalten eine synchronisierte Benutzerdokumentation. Lass die Veröffentlichungsautomatik Metadaten aus konventionellen Commit-Nachrichten ableiten. Verwende dokumentierte Übersteuerungen nur zur beabsichtigten Neuklassifizierung und bearbeite erzeugte Veröffentlichungsartefakte niemals von Hand. Führe die kontinuierliche Integration für nicht vertrauenswürdige Beiträge ohne Geheimnisse und mit reinen Leserechten aus. Vorschauen mit Geheimnissen müssen Abspaltungen überspringen, sofern kein autorisierter Betreuer sie ausdrücklich über einen identitätsgeprüften Befehl auslöst. Registriere jedes bereitgestellte Beispiel in der Erstellungsmatrix und füge einen Kurztest für den erwarteten Pfad, Zustand und Inhalt hinzu. Veröffentlichung oder Bereitstellung sind erst abgeschlossen, wenn erforderliche Prüfungen und Nachweise nach der Bereitstellung bestanden sind.