Étape 4 · Construire

/pulse:test

Lancer les tests automatiques du projet et expliquer chaque échec (lancer), ou écrire les tests d'un code existant à partir des scénarios de la spec (ecrire), par des assistants spécialisés.

    Description

    Les tests automatiques sont de petits programmes qui vérifient, tout seuls, que votre outil fait ce que la spec demande. /pulse:test les lance tous, puis explique chaque échec en une ligne simple : ce qui ne marche pas, la cause, et la tâche concernée quand on la trouve.

    Avec ecrire, la commande écrit les tests d'un code déjà fait mais encore sans tests. Elle part des scénarios de la spec et des critères d'acceptation de l'US. Un assistant écrit ou lance les tests ; un autre, qui n'a pas écrit le code, juge les résultats.

    Chaque échec a une cause : le code lui-même, le test, l'environnement (un outil manquant sur votre ordinateur, par exemple), ou un test instable, qui réussit puis échoue sans raison. Pulse propose la bonne suite pour chacune.

    🧪 Tests : 14 réussis · 1 en échec · 0 instables

❌ Un rendez-vous peut être pris à une date passée
   Cause : le code · Tâche : T4 – Confirmer le rendez-vous

    Le résultat de /pulse:test, avec chaque échec expliqué.

    Pourquoi l'utiliser

    • Tout vérifier en une fois. Une seule commande contrôle que ce qui marchait hier marche encore aujourd'hui.
    • Comprendre chaque échec. Chaque échec est expliqué en langage simple, avec sa cause.
    • Trouver les défauts cachés. Un test fidèle au scénario qui échoue révèle un défaut du code : Pulse vous l'explique et propose de le corriger.
    • Protéger votre travail. Les tests écrits restent dans le projet et vérifient chaque changement à venir.

    Quand l'utiliser

    1. 1 Démarrer
    2. 2 Décrire
    3. 3 Préparer
    4. 4 Construire
    5. 5 Mettre en ligne
    6. 6 Être trouvé
    7. 7 À tout moment
    • Après plusieurs tâches, pour vérifier que tout passe encore.
    • Avant /pulse:commit, pour enregistrer une version qui fonctionne.
    • Sur du code fait sans tests, avec ecrire, pour le protéger.

    Comment la lancer

    /pulse:test [lancer | ecrire <US-XXX | Tn | chemin>]

    Entre crochets [ ] : facultatif. Entre chevrons < > : à remplacer par votre valeur. La barre | sépare les choix possibles.

    • Rien, ou lancer : toute la suite de tests est lancée, et chaque échec expliqué.
    • ecrire (ou écrire), suivi de la cible :
      • une US (US-002) : toutes ses tâches terminées ;
      • une tâche (T7) ;
      • un fichier ou un dossier de votre code.
    /pulse:test
    /pulse:test ecrire US-002

    Ce qu'elle produit

    FichierCe qui change
    Les fichiers de testAvec ecrire : les nouveaux tests, rangés selon l'organisation de votre projet.
    SPEC-US-XXX-<nom>.mdPour une spec ancienne sans scénarios : les scénarios manquants, ajoutés après votre accord.
    aidd_docs/tasks/<groupe>/PLAN-SPEC-US-XXX-<nom>.mdUne ligne au journal du plan : nombre de tests ajoutés et de défauts trouvés.
    Les tests en causeAvec lancer : un test faux ou instable, corrigé si vous le demandez.

    À la fin, Pulse montre seulement les fichiers que cette commande a changés.

    Risques et précautions

    • Rien n'est corrigé sans votre accord. En cas d'échec, Pulse demande : « Corriger maintenant (Recommandé) » ou « Seulement noter les échecs ».
    • Un outil de test s'installe seulement avec votre accord. Sans outil ni accord, la commande s'arrête.
    • Un test qui révèle un défaut reste dans le projet. Le défaut se corrige avec /pulse:fix, pas en supprimant le test.
    • Les tests qui ouvrent le site dans un navigateur se lancent à part. Ils sont plus longs : /pulse:spirc les lance une fois, à la fin d'une user story.
    • Votre besoin reste à vous. Un scénario à préciser qui touche à votre besoin se décide avec vous, puis la spec est mise à jour.

    Problèmes et solutions

    « Aucune commande pour tester »

    Votre projet n'a pas encore d'outil de test. Pulse vous propose d'en installer un ; acceptez pour continuer.

    « Les choix techniques manquent »

    La commande a besoin de docs/technical.md pour savoir comment lancer les tests. Lancez /pulse:tech.

    Un test réussit puis échoue sans raison

    C'est un test instable. Un assistant le corrige, puis Pulse relance les tests concernés ; deux essais au plus.

    L'échec vient de mon ordinateur

    Un outil manque ou n'est pas configuré. Pulse vous guide pas à pas pour le régler.

    Ma spec n'a pas de scénarios

    Elle date d'une version plus ancienne de Pulse. Pulse rédige les scénarios manquants, vous les montre, puis les ajoute à la spec après votre accord.

    Exemples

    /pulse:test

    🧪 Tests : 14 réussis · 1 en échec · 0 instables ❌ Un rendez-vous peut être pris à une date passée. Cause : le code (T4 – Confirmer le rendez-vous). Corriger maintenant (Recommandé) / Seulement noter les échecs ?

    Corriger maintenant

    Je passe par /pulse:fix : d'abord la cause, puis la plus petite correction, puis la preuve que le test passe.

    /pulse:test ecrire US-002

    Je pars des scénarios de la spec de US-002 (liste des rendez-vous du jour) et de ses critères d'acceptation. Un assistant écrit les tests, un autre les lance.

    🧪 Tests : 6 écrits · 5 réussis · 1 en échec (dont 1 défaut du code) Défaut probable : deux rendez-vous à la même heure n'apparaissent qu'une fois dans la liste. Le test reste dans le projet. ➡️ Prochaine étape : /pulse:fix "deux rendez-vous à la même heure n'apparaissent qu'une fois"

    Commandes liées