Mais pourquoi ces tests s'exécutent tout le temps ?

Il y a 1 an et demi, j'avais enfin trouvé un IDE qui me plaît (grâce à vim, Language Server Protocol et Debug Adapter Protocol).

J'utilisais donc depuis des mois avec bonheur vimspector comme interface de debug dans vim.

En début d'année, j'ai commencé à douter de la qualité de vimspector à cause de ce phénomène étrange...

Travaillant sur un projet avec beaucoup de tests unitaires, j'ai préparé une des configurations de vimspector pour n'execéuter qu'un seul fichier de test pour pouvoir me concentrer sur ce que je fais uniquement.

Ça marchait bien, j'avais une commande dans le genre:

node --inspect ./node_modules/.bin/jest --bail 1 --verbose mon_test_unitaire_test.js

jest sait qu'il doit filtrer dans mon projet des fichiers dont le nom correspond à la chaîne de caractère passée en argument.

Un jour, j'ai besoin de debugger le code d'un collègue qui traite des subscriptions, je change donc le filtre et tout va bien.

Depuis, à chaque vois que je veux lancer un test particulier, par exemple à propos de invoice, j'ai certains tests de subscriptions qui s'exécutent aussi (bizarrement, pas tous les fichiers subscriptions, seulement 6 fichiers sur une dizaine).

Au début je me dis que c'est sûrement dû à un cache de configuration de vimspector et donc que ça va passer au redémarrage de ma session de debug.

Eh non, ça persiste, peut être qu'un simple redémarrage de vim ne suffit pas à vider le cache de vimspector ?

Je ne sais plus trop les essais que je fais, sûrement des choses comme supprimer les dossiers de vimspector, ceux de jest (qui a aussi un cache...).

Bon, en soit, ce n'est pas si gênant, je perd un peu de temps (genre moins d'une minute, ces tests ne sont pas trop long), mais ce n'est pas trop grave.

Récemment, j'ai voulu reprendre ce problème frontalement, parce que finalement, à force, c'est déstabilisant et ça me perturbe de ne pas comprendre.

Pour écarter l'hypothèse du cache de configuration de vimspector, j'exécute directement la commande dans mon terminal et je vois exactement le même phénomène: 6 fichiers de tests de subscriptions sont encore exécutés malgré la mise à jour du filtre.

Devenant fou, je repars de la commande de base et j'ajoute les arguments peu à peu:

1. node --inspect ./node_modules/.bin/jest invoices: ok, pas de subscriptions
2. node --inspect ./node_modules/.bin/jest --verbose invoices: ok, pas de subscriptions
3. etc... j'avais pas mal d'options, je les ajoute à mesure, toujours ok.
4. node --inspect ./node_modules/.bin/jest --bail 1 --verbose invoices: les 6 fameux fichiers de subscriptions s'exécutent à nouveau

Donc, finalement je me rend compte que c'est l'option bail qui me pose problème. Jest la décrit ainsi:

--bail
Alias: -b. Exit the test suite immediately upon n number of failing test suite. Defaults to 1.

Oui, je sais, c'est un peu bête de préciser la valeur par défaut, mais ça me rappelle que je peux la changer si besoin.

Bon, je commence à enfin cerner le problème, j'essaie d'exécuter:

node --inspect ./node_modules/.bin/jest --bail=1 --verbose invoices

et paf, ça marche !

En ajoutant le signe égal entre --bail et 1, j'ai précisé à jest, que c'était à --bail que la valeur 1 devait être donnée.

Et là, j'ai enfin compris pourquoi ces fameux tests de subscriptions s'exécutaient tout le temps: les 6 fichiers se nommaient avec une variante du genre subscriptions_1month, subscriptions_1year... ils contenaient tous un 1 dans leur nom !

Voilà, donc toutes mes hypothèses étaient fausses:

1. vimspector fonctionne très bien, pas de problème de cache
2. le cache de jest n'était pas en cause non plus
3. ces fameux 6 fichiers de tests subscriptions avaient quelque chose de spécial par rapport à tous les autres :)
4. je n'ai jamais utilisé la commande comme il faut: j'ai toujours demandé malgré moi à jest de filtrer les fichiers de tests invoice ET ceux qui contiennent 1. Avant d'avoir la fonctionnalité subscriptions, aucun de nos fichiers de tests ne contenaient de 1 dans leur nom, donc je ne l'avais jamais vu.
5. la valeur de l'argument --bail ne peut pas être donnée après un espace, comme c'est le cas dans la plupart des lignes de commandes.

C'est assez dur de comprendre ces bugs qui ne sont pas vraiment du fait du logiciel informatique, mais des hypothèses anodines dont on a l'habitude et qui peuvent parfois ne pas toujours être suivie (la manière de passer des arguments cette fois).