Que puis-je supprimer en restant au vert ?

La partie précédente a bouché le dernier trou du plan de migration. Reste une étape, présente à chacune de ses phases : les tests que l'agent écrit. Prenez le nouveau composant de virement de la partie 4 et demandez à l'agent d'écrire ses tests. Voici ce qui revient en général :

• un AccountsStore mocké ({ accounts: () => [...] } as any) et un Router mocké
• await new Promise((r) => setTimeout(r, 0)) entre les étapes
• des assertions sur component.error() et component.verdict()
• un test qui vérifie que querySelector('button') n'est pas null

Des tests solitaires, des mocks partout, des détails d'implémentation vérifiés. Par défaut, l'agent fait l'inverse d'une bonne suite de tests. Posez donc une seule question à chaque test.

La question

Que pourrais-je supprimer du code de production en restant au vert ?

Le test « le bouton existe ». Je pourrais supprimer tout le flux d'envoi, il resterait vert. Supprimez le test.

« Un compte bloqué affiche un message », avec un store mocké. C'est le store mocké qui renvoie le message : je pourrais contourner canTransfer(), le test resterait vert. Or un compte bloqué, c'est une exigence que le client voit. Réécrivez le test avec le vrai store, et vérifiez le message à l'écran.

« Navigue après le virement », avec un store et un router mockés. Je pourrais supprimer l'appel à store.transfer(), le router mocké enregistrerait quand même la navigation. Réécrivez le test avec le vrai store branché sur le faux backend, puis vérifiez deux choses : le solde a baissé, et la route a changé.

Les pauses en setTimeout. Remplacez-les par await fixture.whenStable().

Lors des sessions du workshop sur ce composant, environ la moitié des tests générés a été supprimée, un quart réécrit via le DOM, et un quart conservé. Le premier jet de la suite de tests que livre l'agent est une liste de candidats, et c'est la revue qui prend le temps.

Les signaux d'alerte

Ces lignes vont dans le AGENTS.md du dépôt de démonstration, pour que la prochaine fournée de tests soit meilleure avant même toute revue :

• un double de test pour un élément interne à l'unité ; seule la frontière, le faux backend, a droit à un faux
• des pauses (sleep) ou des setTimeout dans un test
• des assertions sur les champs du composant au lieu du DOM ou de l'état du store
• une valeur attendue recalculée par le code testé au lieu d'être écrite en dur
• un élément dont on vérifie la présence alors qu'il existe dès le premier rendu, quelles que soient les données
• une exécution au vert dont la console affiche une erreur

Le dernier point est le moins coûteux à vérifier, et le plus souvent oublié. Une erreur backend égarée dans une exécution au vert signifie en général qu'un test est passé sans vérifier ce qui a échoué.

Quand la question est aussi précise, l'agent juge ses propres tests de façon honnête. Il en marque souvent une bonne partie lui-même, et votre revue devient un contrôle de ses verdicts.

À quoi ressemble un test conservé

Extrait de new-transfer.spec.ts, sur track1/m2-ngmodule-solution :

it('moves the money and returns to the account', async () => {
  const { harness, type, click, store, router } = await open();
  type('Amount (MAD)', '500');
  type('Label', 'Loyer');
  await click('Confirm transfer');
  await harness.fixture.whenStable();
  harness.detectChanges();
  expect(store.accounts()[0].balanceMad).toBe(1500);
  expect(router.url).toBe('/accounts/a-1');
});

open() ouvre l'URL avec le vrai store sur un faux backend instantané, où le compte démarre à 2 000 MAD. type() trouve un champ par son libellé et click() un bouton par son nom, comme un utilisateur. Le 1500 est donc l'exigence écrite noir sur blanc : 2 000 moins les 500 saisis. Retirez l'appel à store.transfer() du composant, et ce test passe au rouge. C'est toute la définition d'un test qui mérite d'être gardé.

Retour à la réunion

La partie 1 commençait par un diff de bien plus de mille lignes et une réunion où seule la démo comptait. Voici le même genre de migration dans le dépôt de démonstration, mesuré avec git diff --stat sur track1/m2-ngmodule-solution et compté par chemin :

• Figer (tâche 000) : 141 lignes, uniquement des tests. Aucune ligne de production modifiée.
• Construire à côté et basculer (tâche 002) : 233 lignes de code de production, pour l'essentiel un composant de 223 lignes, plus 271 lignes de tests et le squelette produit par le générateur. La bascule elle-même tient en une ligne modifiée.
• Supprimer (tâche 003) : 545 lignes retirées, 1 ajoutée, aucune logique.

Trois fichiers de tâche, chacun une pull request qu'une personne peut lire d'une traite, et aucune étape qui oblige quelqu'un à se souvenir du fonctionnement de l'ancien écran. L'écran AngularJS de la partie 6 a été construit à côté et basculé de la même façon sur track1/m2b-angularjs-solution, jusqu'à un changement de route de quatre lignes. Ce sont des chiffres du dépôt de démonstration, pas ceux d'un client. Les vôtres sortent de la même commande.

Dès lundi

• Pour chaque test généré, demandez-vous ce que vous pourriez supprimer en restant au vert. Supprimez ou réécrivez en conséquence.
• Ajoutez les signaux d'alerte à votre fichier de règles.
• Lancez git diff --stat sur vos trois prochaines pull requests d'agent, et notez à côté de chacune les heures de revue. Apportez ces deux colonnes à la réunion, pas la démo. Elles répondent à la question de la partie 1 : pourquoi ne sommes-nous pas plus rapides ?

Exercice : la scène 3 du module 2 dans le dépôt de démonstration. Partez de votre branche de la scène 2, ou de git switch -c m2/tests origin/track1/m2-ngmodule-solution. Référence : les cinq tests de new-transfer.spec.ts sur cette branche. Retirez ensuite les règles de test de AGENTS.md, relancez, et observez la différence.

Parcours 1, partie 7 et dernière de ce parcours, dans la série gratuite qui accompagne le workshop Vite et sûr : l'IA dans votre code Angular. La partie de clôture est la politique que votre équipe met par écrit.