SenroAI/agent-skills

Senro-Tests

Generieren Sie genau die vom Benutzer angeforderte Anzahl nützlicher Senro-Testfälle aus dem Repository, das die Seite enthält, die der Benutzer zu Senro hinzugefügt hat. Der Coding-Agent führt weder WebMCP noch die generierten Tests aus; Senro führt die Suite später gegen die registrierte Seite aus.

Arbeitsablauf

1. Bestätigen Sie, dass das aktuelle Repository die Seite enthält, deren WebMCP-Verhalten getestet wird. Behandeln Sie das Repository als die Quelle der Wahrheit.

2. Inspizieren Sie das Repository, bevor Sie etwas generieren. Schließen Sie .git, Abhängigkeitsverzeichnisse, Build-Ausgaben, Coverage-Ausgaben und generierte Dateien aus.

3. Bestimmen Sie, wie die Website ihre WebMCP-Tools mit dem eigenen Quellcode, Framework, Abhängigkeiten, Tests, Fixtures und der Dokumentation des Projekts bereitstellt. Gehen Sie nicht von einer bestimmten WebMCP-API, einem bestimmten Framework, einer bestimmten Dateistruktur oder einem bestimmten Registrierungsmuster aus.

4. Erstellen Sie ein internes Inventar jedes entdeckten Tools mit Name, Beschreibung, Eingabeschema, Annotationen, Implementierung und verfügbaren Beispielen.

5. Stoppen Sie und berichten Sie klar, wenn aus dem Repository keine WebMCP-Tools ermittelt werden können. Falls mehrere nicht zusammenhängende Websites oder Anwendungen vorhanden sind, identifizieren Sie diese und fragen Sie, welche verwendet werden soll.

6. Lesen Sie die relevanten Routen, Komponenten, Datendateien, Fixtures, Validierungscode, Dokumentation und vorhandenen Tests, um reale Benutzerreisen und sichtbare Erfolgs- und Fehlerzustände abzubilden.

7. Lesen Sie references/import-format-v1.md, bevor Sie Testfälle schreiben. Verwenden Sie nur die dort dokumentierten Felder und Strukturen.

8. Generieren Sie genau die angeforderte Anzahl unterschiedlicher Testfälle. Decken Sie die stärksten Benutzerreisen des Repositories ab, einschließlich erfolgreicher Workflows, Randbedingungen, ungültiger Eingaben, leerer Ergebnisse, Wiederherstellung, folgenreicher Aktionen und sichtbarer Zustandsbehauptungen, wo die Quelle dies unterstützt.

9. Wenn das Repository die angeforderte Anzahl sinnvoller, quellenbasierter Fälle nicht unterstützen kann, melden Sie die Einschränkung und stoppen Sie. Füllen Sie die Suite nicht mit erfundenen Szenarien, Werten oder Verhalten auf.

10. Verwenden Sie nur Tool-Namen und Argumente, die von der entdeckten Quelle unterstützt werden. Erfinden Sie niemals IDs, Konten, Produkte, Enum-Werte oder Backend-Zustände. Verwenden Sie zielorientierte Tests nur, wenn ein präziser Laufzeitwert nicht sicher ermittelt werden kann.

11. Verwenden Sie erwartete Tool-Aufrufe nur, wenn die Quelle den erwarteten Pfad unterstützt. Erzwingen Sie keine exakte Ablaufbahn in einem Workflow, bei dem mehrere gültige Pfade möglich sind.

12. Erstellen Sie ./senro bei Bedarf. Schreiben Sie die Suite in ./senro/test-cases.json. Wenn diese Datei bereits auf der Festplatte existiert, verwenden Sie das nächste verfügbare numerische Suffix, z. B. ./senro/test-cases-2.json. Eine gelöschte, von Git verfolgte Datei ist keine Kollision. Bewahren Sie Suiten direkt in ./senro auf; archivieren oder verschieben Sie vorhandene Dateien nicht.

13. Führen Sie den gebündelten strukturellen Preflight-Validator gegen die genaue Datei aus, die Sie generiert haben, bevor Sie den Erfolg melden:

    node <skill-root>/scripts/validate-tests.mjs <output-path>
    

14. Melden Sie den genauen Ausgabepfad, die Testanzahl, die Abdeckung der Benutzerreisen und etwaige Annahmen. Behaupten Sie nicht, dass ein Test zur Laufzeit verifiziert wurde; Senro muss die Suite gegen die Live-Seite ausführen.

Ausgaberegeln

• Schreiben Sie ein JSON-Objekt mit einem tests-Array.
• Halten Sie Testnamen präzise und unter 70 Zeichen.
• Schreiben Sie natürliche Benutzeranfragen. Fügen Sie technische Details nur dann ein, wenn sie für das zu testende Verhalten wesentlich sind.
• Variieren Sie, wo die Quelle dies unterstützt, Gesprächsmodi, Bewertungstypen und die Komplexität der Benutzerreisen. Verwenden Sie skriptgesteuerte Gespräche für explizite Anfragen und simulierte Gespräche für Klärungen oder mehrschrittige Entscheidungen. Erzwingen Sie keine Vielfalt, wo sie keine nützliche Abdeckung hinzufügt.
• Geben Sie skriptgesteuerten Tests genau eine anfängliche Benutzernachricht.
• Geben Sie simulierten Tests eine leere Liste verfasster Nachrichten und keine verfassten Folgenachrichten.
• Stellen Sie sicher, dass jeder Test ein Ziel, einen erforderlichen erwarteten Aufruf oder eine Seitenprüfung hat.
• Beschreiben Sie, was der Agent bei erfolgreichen Ergebnissen erreichen soll. Verwenden Sie Tool-Aufruferwartungen für notwendige Aufrufe und Argumente sowie Seitenprüfungen für den endgültigen Seitenzustand. Schreiben Sie keinen Implementierungspfad in ein Ergebnis vor, wenn mehrere gültige Pfade existieren.
• Halten Sie Setup-Aufrufe konkret; verwenden Sie niemals Matcher-Operatoren in Setup-Argumenten.
• Verwenden Sie stabile Selektoren aus der Quelle für Seitenprüfungen.
• Bestätigen Sie den stabilen endgültigen Seitenzustand, nicht temporäre Nachrichten, die spätere gültige Aktionen löschen könnten. Überprüfen Sie das Zwischenverhalten durch unterstützte Tool-Aufruf- und Ergebnisprüfungen oder das erfolgreiche Ergebnis.
• Verwenden Sie expectedCall: null, wenn die Tool-Aufrufbewertung deaktiviert ist. Es verbietet keine Tool-Aufrufe.
• Ändern Sie nicht den Quellcode der Website, während Sie die Suite generieren.
• Schreiben Sie keine Geheimnisse, Anmeldeinformationen oder private Kundendaten in die Suite.

Referenzen

• Importformat