Tests: les 22 tests de commandes ne testent que dist/ compilé, jamais run() (coverage réelle 22.6%)

[julesbonnard]

Constat

Revue des tests du projet (30 tests, 8 fichiers). Les 22 tests de commandes (get, login, logout, search, notifications/*) ne testent que le manifest oclif compilé dans dist/ (Config.load().findCommand(...)), jamais run(). Preuve : en supprimant dist/, ces tests échouent — ils ne lisent donc jamais src/. Modifier la logique métier dans src/commands/** sans rebuild laisse la suite verte.

Coverage réelle mesurée avec c8 (le seul outil fiable ici, vu l'ESM + loader tsx que nyc ne voit pas) : 22.58% lignes global, 0% sur base-command.ts, toutes les commandes, et schemas/notification.ts.

À faire

• Ajouter @oclif/test en devDependency (fournit runCommand, qui exécute réellement run() avec mocks/stubs d'API)
• Réécrire les 22 tests "metadata" en tests de comportement réel (mock de l'API, assertion sur la sortie/les effets)
• Ajouter des tests pour base-command.ts (auth, chargement/sauvegarde userConfig, initApiCore(), listener tokenChanged) — cœur transversal actuellement à 0%
• Ajouter des tests pour la logique pure sans I/O, actuellement zéro couverture :
  • src/commands/login/index.ts : timeConvert(), getClientId() (décodage base64, cas anonymous)
  • src/commands/get/index.ts : branchement afpshortid (id.length===7) vs UNO, mode --extended
  • src/commands/search/index.ts:45-49 : résolution des fields, émission NDJSON sous --json
  • src/commands/notifications/services/create.ts : JSON.parse + validation Zod par type de service
  • src/schemas/notification.ts : schémas Zod (HttpServiceDataSchema, MailServiceDataSchema, JmsServiceDataSchema, SqsServiceDataSchema), testables unitairement sans I/O
• Supprimer les 7 doublons should be loadable strictement subsumés par un test voisin (get, login, search, notifications/services, notifications/subscriptions)
• Configurer c8 pour le coverage : ajouter en devDependency, script test:coverage (c8 --reporter=text --reporter=html --all --include 'src/**/*.ts' -- mocha --forbid-only "test/**/*.test.ts"), et un .c8rc.json (all: true, include: ["src/**/*.ts"])
• Retirer @types/chai des devDependencies (dépendance morte, aucun fichier de test n'importe chai, tous utilisent node:assert)
• Ajouter des tests pour src/components/table.ts (lignes 172-300 non couvertes : sort, filter, --columns, troncature de largeur)

Contexte

Revue effectuée le 2026-08-27 (agent claude), voir historique de conversation pour le détail complet.

[julesbonnard]

PR ouverte : #4

Correction du diagnostic initial : ce n'est pas oclif.commands: "./dist/commands" dans package.json le problème. La cause réelle est que le lecteur de tsconfig d'@oclif/core (read-tsconfig.js) appelle l'API TypeScript classique (parseConfigFileTextToJson), non exposée par TypeScript 7 (compilateur natif utilisé ici) — la lecture échoue silencieusement et la réécriture dist → src ne se déclenche jamais, quel que soit NODE_ENV. Détail complet dans la description de la PR et dans CLAUDE.md (nouvelle section Testing).

Effet de bord découvert au passage, documenté mais non corrigé ici (hors périmètre de ce ticket) : ./bin/dev.js est cassé par le même bug sans build préalable.