---
# 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é.
