Règle .claude/rules/tests.md limitée aux fichiers de test

---
# Cette règle ne se charge que lorsque Claude lit un fichier correspondant
# à l'un de ces motifs glob. Adaptez-les à l'organisation de vos tests.
paths:
  - "**/*.test.{ts,tsx,js}"
  - "**/*.spec.{ts,tsx,js}"
  - "tests/**/*.py"
---
 
# Règles pour les fichiers de test
 
- Un test vérifie un seul comportement ; son nom décrit ce comportement
  (« renvoie 404 si l'utilisateur n'existe pas »), pas la fonction testée.
- Structure Arrange / Act / Assert, avec une ligne vide entre chaque bloc.
- Pas d'appel réseau réel : utiliser les doubles de test existants
  (voir les fixtures et helpers déjà présents avant d'en créer de nouveaux).
- Pas de dépendance à l'ordre d'exécution ni à l'heure système :
  figer le temps avec l'utilitaire prévu par le framework de test.
- Tester les cas limites : entrée vide, valeur nulle, erreur du service appelé.
- Ne jamais supprimer, ignorer (`skip`) ou affaiblir une assertion pour faire
  passer un test : signaler l'échec et proposer une correction du code.
- Après modification, lancer uniquement les tests du fichier concerné,
  puis la suite complète si le changement touche du code partagé.

Le dossier .claude/rules/ permet de découper les instructions d'un projet en plusieurs fichiers Markdown, un par thème. Leur principal intérêt : une règle peut être limitée à certains chemins. Elle n'est alors chargée dans le contexte que lorsque Claude lit un fichier correspondant, au lieu d'alourdir chaque session. Ce modèle regroupe les consignes d'écriture de tests et ne s'active que sur les fichiers de test.

Le frontmatter paths

Le fichier commence par un bloc YAML entre deux lignes ---. Le seul champ que Claude Code lit dans une règle est paths : une liste de motifs glob, sous forme de liste YAML ou de chaîne séparée par des virgules. Les accolades couvrent plusieurs extensions dans un seul motif, par exemple **/*.test.{ts,tsx,js}. Tout autre champ est ignoré, et une règle sans paths est chargée systématiquement.

Le déclenchement a lieu quand Claude lit un fichier correspondant, pas à chaque action. Si Claude crée un nouveau fichier de test sans en avoir lu aucun, la règle peut ne pas encore être en contexte : citer un test existant dans votre demande aide.

Ce que contient le modèle

• Un test par comportement, nommé d'après ce comportement.
• La structure Arrange / Act / Assert.
• Pas d'appel réseau réel ni de dépendance à l'heure ou à l'ordre d'exécution.
• Les cas limites à couvrir systématiquement.
• L'interdiction d'ignorer ou d'affaiblir une assertion pour obtenir un succès.
• La stratégie d'exécution : d'abord les tests du fichier, puis la suite complète si du code partagé a changé.

Comment l'adapter

1. Motifs : alignez paths sur votre organisation. Un projet Python avec des fichiers test_*.py utilisera par exemple **/test_*.py ; un projet qui range tout dans __tests__/ peut viser **/__tests__/**.
2. Outils : nommez vos utilitaires réels (fixtures, fabriques de données, horloge simulée) pour que Claude les réutilise au lieu d'en créer de nouveaux.
3. Commandes : si l'exécution d'un seul fichier de test demande une syntaxe particulière, indiquez-la.

Pièges fréquents

• YAML invalide : si le frontmatter ne se lit pas, Claude Code l'ignore et charge la règle comme si elle n'avait pas de paths, donc en permanence. claude --debug affiche l'erreur d'analyse.
• Crochets dans un motif : [ ouvre une classe de caractères ; échappez-le (\[) pour viser un crochet littéral.
• Règles contradictoires entre CLAUDE.md et .claude/rules/ : relisez l'ensemble périodiquement.
• Chemins relatifs : les motifs se lisent depuis la racine du projet ; *.md ne vise que les fichiers Markdown de la racine, pas ceux des sous-dossiers.

La leçon Le fichier CLAUDE.md replace les règles par chemin dans l'ensemble du système de mémoire de Claude Code.