Ignored Test.

Un test existe dans la suite mais est empêché de s'exécuter de façon permanente. Il compte toujours comme un « test » dans le fichier, mais ne contribue à aucune vérification. Surveillez les marqueurs skip/ignore, les blocs préfixés par x, et le code de test enfoui dans des commentaires — souvent assortis d'une excuse vague comme « flaky » ou « à corriger plus tard ».

// modificateurs skip/disabled — jamais exécutés
describe.skip('checkout flow', () => { /* ... */ });
it.skip('applies the discount', () => { /* ... */ });

// préfixés par x (jasmine/jest/mocha) — même effet
xit('rejects negative amounts', () => { /* ... */ });
xdescribe('payments', () => { /* ... */ });

// test mis en commentaire — invisible pour l'exécuteur ET le rapporteur
// it('retries on 503', async () => {
//   await expect(client.fetch()).resolves.toBeOk();
// });

// JUnit : @Ignore / @Disabled avec une raison vaseuse
@Ignore("disabled for now as this test is too flaky")
@Test public void peerPriority() { /* ... */ }

Signes révélateurs dans le rapport de tests : un décompte « ignorés »/« en attente » non nul que personne ne regarde, des suites qui ont rétréci silencieusement au fil du temps, et des exclusions sans ticket lié ni expiration. Les return conditionnels en tête de test (if (process.platform === 'win32') return;) sont une variante plus sournoise qui dissimule l'exclusion aux compteurs d'exclusions.

Tout marqueur n’est pas ce smell. test.todo('handles expired coupons — PAY-412') n’a pas de corps, apparaît dans le rapport comme todo (jamais comme réussi) et renvoie à un ticket : c’est une ébauche honnête et visible. Un test au corps vide qui est rapporté vert relève d’un autre problème : le test vide.

Pourquoi cela se produit

• Un test s'est mis à échouer (une véritable régression, une dépendance temporelle instable, un changement d'environnement/de version) et l'ignorer était le moyen le plus rapide d'obtenir un build vert ou de débloquer une fusion.
• Un test a été écrit avant l'implémentation, mis de côté avec xit/it.skip sans ticket, et personne n'y est jamais revenu. (Un test.todo rattaché à un ticket reste au moins visible dans chaque rapport.)
• Des migrations (nouveau framework, runtime ou API) ont cassé le test, et il a été mis de côté « temporairement ».
• L'exclusion devait durer une après-midi ; sans rappel, expiration ni ticket de suivi, elle devient permanente.

Pourquoi c'est nuisible

• Fausse confiance. Un test ignoré ressemble à de la couverture dans le fichier et le diff de la PR, mais n'exerce rien. Le chemin de code qu'il prétendait protéger est désormais sans garde-fou, et tout le monde le suppose sûr.
• Pourrissement. Un test ignoré est toujours compilé et vérifié par le typage, mais il ne s'exécute jamais : personne ne remarque quand ses fixtures, ses valeurs attendues et ses hypothèses cessent de correspondre au code. Un test mis en commentaire est pire : il n'est même pas compilé, si bien que les changements d'API le cassent en silence et que personne ne s'en aperçoit avant de le décommenter. Plus ils restent ainsi, plus ils s'éloignent de la réalité, jusqu'à ce que les réactiver coûte plus cher que de les réécrire.
• Régressions cachées. Le bogue ou le comportement instable qui a motivé l'exclusion est toujours là — il a simplement été réduit au silence. Ignorer traite le symptôme (une barre rouge) au lieu de la maladie.
• Bruit et érosion. Des décomptes de tests « ignorés » qui s'installent entraînent l'équipe à ne plus prêter attention au rapport de tests, ce qui laisse passer de nouvelles exclusions inaperçues. Le code de test mort ou mis en commentaire ajoute aussi une charge de lecture et de maintenance sans aucun bénéfice.

Traitez chaque test ignoré comme une décision à prendre maintenant, et non à reporter indéfiniment.

1. Triez chaque exclusion. Pour chaque test désactivé ou mis en commentaire, décidez : le corriger, le supprimer, ou le mettre en quarantaine avec une expiration et un ticket de suivi. « Le laisser ignoré pour toujours » n'est pas une option. Un test.todo qui cite un ticket est déjà une ébauche honnête : ne le gardez que tant que ce ticket est ouvert.
2. Corrigez et réactivez si le comportement compte toujours. Si le test est instable, corrigez l'instabilité (maîtrisez le temps, l'aléatoire, l'asynchrone et l'état partagé) au lieu de l'ignorer.
3. Supprimez-le si la fonctionnalité a disparu ou si le test est obsolète. Un test supprimé est honnête ; un test ignoré ment. Le contrôle de version s'en souvient si jamais vous en avez besoin — alors ne mettez jamais en commentaire un test au lieu de le supprimer.
4. Si vous devez ignorer temporairement, rendez-le bruyant et limité dans le temps : incluez toujours une raison et un lien de suivi, et préférez un mécanisme qui apparaît dans les rapports et échoue une fois l'échéance passée, afin que l'exclusion ne puisse pas pourrir.
5. Stoppez l'hémorragie avec le lint/la CI. Activez une règle « pas de tests désactivés » pour que les nouvelles exclusions soient repérées en revue, et traitez le décompte d'exclusions existant comme un backlog à ramener à zéro.

// avant — silencieux, permanent, non suivi
it.skip('refunds the full amount on cancel', async () => {
  await expect(refund(order)).resolves.toEqual({ amount: 100 });
});

// après — corrigé et de nouveau exécuté (cause profonde : total en virgule flottante)
it('refunds the full amount on cancel', async () => {
  await expect(refund(order)).resolves.toEqual({ amount: 100 });
});

// solution intermédiaire acceptable — visible, attribuée et avec expiration
it.skip('refunds the full amount on cancel — flaky clock, see JIRA-1234 (remove by 2027-03-01)', async () => {
  /* ... */
});

// avant
@Ignore("too flaky")
@Test public void peerPriority() { ... }

// après : corriger la dépendance temporelle et réactiver, ou supprimer si obsolète
@Test public void peerPriority() { ... }