SenroAI/agent-skills

Tests Senro

Générer exactement le nombre de cas de test Senro utiles demandé par l'utilisateur depuis le dépôt contenant la page qu'il a ajoutée à Senro. L'agent de codage n'exécute pas WebMCP ni les tests générés ; Senro exécute la suite ultérieurement contre la page enregistrée.

Workflow

1. Confirmer que le dépôt courant contient bien la page dont le comportement WebMCP est testé. Traiter le dépôt comme la source de vérité.

2. Inspecter le dépôt avant de générer quoi que ce soit. Exclure .git, les répertoires de dépendances, les sorties de build, les sorties de couverture et les fichiers générés.

3. Déterminer comment le site expose ses outils WebMCP en utilisant le code source, le framework, les dépendances, les tests, les fixtures et la documentation du projet. Ne pas supposer d'API WebMCP, de framework, d'organisation de fichiers ou de schéma d'enregistrement particulier.

4. Construire un inventaire interne de chaque outil découvert : nom, description, schéma d'entrée, annotations, implémentation et exemples disponibles.

5. S'arrêter et signaler clairement si aucun outil WebMCP ne peut être établi à partir du dépôt. Si plusieurs sites ou applications non liés sont présents, les identifier et demander lequel utiliser.

6. Lire les routes, composants, fichiers de données, fixtures, code de validation, documentation et tests existants pertinents pour cartographier les parcours utilisateur réels ainsi que les états de succès et d'échec visibles.

7. Lire references/import-format-v1.md avant d'écrire les cas de test. Utiliser uniquement les champs et structures qui y sont documentés.

8. Générer exactement le nombre demandé de cas de test distincts. Couvrir les parcours les plus significatifs du dépôt, y compris les workflows réussis, les conditions limites, les entrées invalides, les résultats vides, la récupération, les actions conséquentes et les assertions d'état visibles lorsque la source les supporte.

9. Si le dépôt ne peut pas supporter le nombre demandé de cas significatifs et fondés sur la source, signaler la limitation et s'arrêter. Ne pas gonfler la suite avec des scénarios, valeurs ou comportements inventés.

10. Utiliser uniquement les noms d'outils et arguments supportés par la source découverte. Ne jamais inventer d'identifiants, comptes, produits, valeurs d'énumération ou état backend. Utiliser des tests sans objectif précis (goal-only) lorsqu'une valeur d'exécution exacte ne peut pas être établie de manière fiable.

11. Utiliser des appels d'outil attendus uniquement lorsque la source supporte le chemin attendu. Ne pas forcer une trajectoire exacte sur un workflow où plusieurs chemins valides sont possibles.

12. Créer ./senro si nécessaire. Écrire la suite dans ./senro/test-cases.json. Si ce fichier existe déjà sur le disque, utiliser le suffixe numérique disponible suivant, par exemple ./senro/test-cases-2.json. Un fichier supprimé suivi par Git n'est pas une collision. Conserver les suites directement dans ./senro ; ne pas archiver ni déplacer les fichiers existants.

13. Exécuter le validateur structurel pré-intégré sur le fichier exact que vous venez de générer avant de signaler le succès :

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

14. Signaler le chemin de sortie exact, le nombre de tests, la couverture des parcours et toutes les hypothèses. Ne pas prétendre qu'un test a été vérifié en runtime ; Senro doit exécuter la suite contre la page en direct.

Règles de sortie

• Écrire un seul objet JSON contenant un tableau tests.
• Garder les noms de tests concis et sous 70 caractères.
• Rédiger des requêtes utilisateur naturelles. Inclure des détails techniques uniquement lorsqu'ils sont essentiels au comportement testé.
• Là où la source le permet, varier les modes de conversation, les types d'évaluation et la complexité des parcours. Utiliser des conversations scriptées pour les requêtes explicites et des conversations simulées pour les clarifications ou les décisions multi-tours. Ne pas forcer la variété là où elle n'ajoute pas de couverture utile.
• Donner aux tests scriptés exactement un message utilisateur initial.
• Donner aux tests simulés une liste de messages auteurs vide et aucun suivi auteur.
• Assurer que chaque test a un objectif, un appel attendu requis ou une vérification de page.
• Décrire ce que l'agent doit accomplir dans les résultats réussis. Utiliser les attentes d'appels d'outils pour les appels et arguments nécessaires, et les vérifications de page pour l'état final de la page. Ne pas prescrire un chemin d'implémentation dans un résultat lorsque plusieurs chemins valides existent.
• Garder les appels de configuration concrets ; ne jamais placer d'opérateurs de correspondance dans les arguments de configuration.
• Utiliser des sélecteurs stables de la source pour les vérifications de page.
• Asserter un état final de page stable, pas des messages temporaires que des actions ultérieures valides pourraient effacer. Vérifier le comportement intermédiaire via des vérifications d'appels d'outils et de résultats supportés, ou via le résultat réussi.
• Utiliser expectedCall: null lorsque l'évaluation d'appel d'outil est désactivée. Cela n'interdit pas les appels d'outils.
• Ne pas modifier le code source du site pendant la génération de la suite.
• Ne pas écrire de secrets, informations d'identification ou données client privées dans la suite.

Références

• Format d'import