Stratégie de test des gardes (IAM) : ne pas retester 401/403 dans chaque spec de contrôleur

[shikanime]

Contexte

Chaque spec de contrôleur server-nestjs redéclare aujourd'hui le même échafaudage IAM : overrideGuard(UserGuard) / overrideGuard(ProjectGuard) avec un stub canActivate: () => true, et plusieurs vérifient en plus le refus (401/403) sur leurs routes. Les gardes ont par ailleurs leurs propres specs unitaires dédiées (user.guard.spec.ts, project.guard.spec.ts).

Constat sur main : 12 specs de contrôleur appellent overrideGuard, dont certaines assertent aussi des 403 par persona.

Question ouverte

La couverture IAM (401/403 par rôle et par projet) doit-elle être vérifiée une fois au niveau des gardes et d'un petit nombre de tests d'API représentatifs, plutôt que répétée dans chaque spec de contrôleur ? Si oui, où vit la frontière : specs des gardes seules, un fichier d'e2e API dédié, ou les deux ?

Questions secondaires

• Que devient le refus de la route publique (UserGuard must not run on the public list route, stage.controller.spec) — conservé au cas par cas ou couvert par la spec du garde ?
• Les specs de contrôleur doivent-elles systématiquement stubber les gardes (canActivate: () => true) pour ne tester que la logique du contrôleur ?

Dépôts concernés

• cloud-pi-native/console

PR liée

• test(system-settings): drop guard metadata specs #2810 (retire les specs de metadata de garde de system-settings.controller.spec.ts ; le corps documente la règle convergée « pas de specs de guard par metadata », preuve HTTP par persona)