2026 Bun 1.4.4 --changed : que faire si les tests de validation par e-mail sont ignorés ?

Diagnostiquer Bun 1.4.4 --changed pour les tests de validation par e-mail

La commande incrémentale répond à une question de sélection : quels tests le lanceur choisit-il au regard des changements qu’il observe ? Elle ne répond pas, à elle seule, à la question plus large : le parcours d’inscription ou de vérification par e-mail est-il entièrement validé ?

La documentation de Bun décrit --changed comme un moyen de lancer les tests associés aux fichiers modifiés, selon les relations que le lanceur peut repérer. Les notes de Bun 1.4 exposent ce mécanisme ; les notes de Bun v1.4.4 signalent aussi des corrections de stabilité concernant bun test et bun test --changed. Cela ne signifie pas que cette version ajoute une fonction spécialisée pour les tests de courrier, ni qu’elle garantit la sélection de chaque test lié à un changement. Pour ces points, la référence est le fonctionnement décrit dans la documentation officielle de Bun. Le résultat à retenir est celui de votre exécution locale ou de votre tâche d’intégration continue, et non une supposition fondée sur le seul code de sortie.

Il faut séparer trois preuves :

• Le test a été sélectionné : le fichier concerné apparaît dans la sortie ou le rapport.
• Le test a réussi : les assertions qui y figurent sont passées.
• Le message est arrivé dans une boîte de réception : un contrôle distinct a permis de lire le message attendu.

La première preuve ne démontre pas que les assertions ont réussi ; la deuxième ne prouve pas que le message a quitté le système d’envoi ou qu’il a été reçu. La troisième ne garantit pas, à elle seule, que tous les cas limites du parcours applicatif ont été couverts.

Première vérification : déterminer ce que la commande compare

Avant d’inspecter les tests, relevez le contexte exact dans lequel --changed est lancé. La sélection dépend du point de comparaison retenu et des changements disponibles dans l’environnement Git. Entre un poste de développement et un agent d’intégration continue, le dépôt peut ne pas avoir le même historique ou le même état de branche. Un clone superficiel, une fusion ou une différence entre la branche courante et la référence choisie peut donc modifier les fichiers considérés comme changés.

Conservez la commande exacte, la version affichée par bun --version, la branche ou la révision de référence et la sortie pertinente du lanceur. Sous Bun 1.4.4, vérifiez également que l’agent d’intégration continue utilise bien cette version, et pas seulement le poste du développeur. Les notes de publication de Bun v1.4.4 confirment que cette version comporte des corrections de stabilité associées au lanceur de tests ; elles ne permettent pas de déduire la cause d’une sélection manquante dans un dépôt particulier.

Pourquoi bun test --changed peut-il ne pas lancer le test de validation par e-mail ? Une piste fréquente est un décalage entre les fichiers modifiés et les dépendances reconnues par le lanceur. Une modification du composant d’inscription peut être directement reliée à un test qui importe ce composant. En revanche, une relation construite indirectement par configuration, génération de fichiers ou assemblage à l’exécution peut être moins évidente à établir. Vérifiez donc les limites du graphe de dépendances que le lanceur peut observer, au lieu de supposer qu’une relation métier sera automatiquement reconnue.

Comparez la sortie de Bun au diff correspondant à la référence réellement utilisée. Repérez notamment les modèles de message, les gestionnaires d’inscription et de renvoi, le code qui crée ou interprète un lien de vérification, ainsi que les fonctions qui modifient l’état du compte après validation. Examinez aussi les fichiers de configuration, de génération ou de routage susceptibles d’influer sur ce parcours.

La documentation de configuration des tests Bun permet de vérifier les paramètres de découverte et d’exécution. Elle ne remplace pas l’examen du dépôt : si une partie du parcours est générée ou assemblée indirectement, établissez quels modules le test importe et quelles conditions déterminent son exécution.

Deuxième vérification : prouver quels tests ont été retenus

Un code de sortie réussi indique que la commande s’est achevée sans échec signalé parmi les tests exécutés. Il ne prouve pas que la suite de régression des e-mails faisait partie de cette sélection. Pour lever l’ambiguïté, recueillez une preuve au niveau des fichiers et, si possible, au niveau des cas exécutés.

Conservez la sortie complète de bun test --changed, plutôt que la seule dernière ligne du terminal. Repérez les fichiers de test prévus pour les parcours d’inscription, de validation du lien, de vérification par code ou de changement d’état du compte. Si le rapport fournit les noms des tests, comparez-les aussi aux cas qui devraient couvrir ces comportements. Confrontez enfin la liste obtenue au diff : une modification du modèle de courrier sans exécution du test qui le rend doit déclencher une vérification supplémentaire.

Comment confirmer que les bons fichiers de test ont été sélectionnés ? Gardez une trace des fichiers touchés, des fichiers de test effectivement retenus et des résultats des cas associés. Si votre configuration ne permet pas de produire cette liste clairement, lancez séparément le fichier concerné avec une commande explicite et consignez ce résultat dans une tâche distincte. La documentation Bun décrit les options du lanceur ; la forme exacte du rapport dépend néanmoins de la commande et de la configuration utilisées.

Dans un dépôt où les tests sont dispersés, adoptez des conventions qui rendent leur repérage plus simple : noms de fichiers cohérents, imports explicites des fonctions testées et regroupement des cas critiques du parcours. Le but n’est pas de contourner --changed, mais de rendre plus visible la relation entre le code modifié et les tests. Si une génération de code ou une configuration participe au parcours, ajoutez une tâche qui exécute les tests associés à cette zone au lieu de dépendre uniquement de l’inférence du lanceur.

Choisir la vérification à lancer selon la preuve nécessaire

Utilisez cette liste de décision pour déterminer la prochaine action, plutôt que de vous fier à une impression générale de réussite :

• Si le fichier de test attendu apparaît dans la sortie et que les cas prévus ont réussi, consignez la sélection et le résultat. Ajoutez une intégration plus large si le changement touche un parcours critique.
• Si le fichier n’apparaît pas, ou si la sortie ne permet pas de le confirmer, lancez explicitement le test concerné et examinez pourquoi la relation de dépendance n’a pas été prise en compte.
• Si la modification touche un modèle, un lien de validation ou une mise à jour de compte, lancez une tâche d’intégration qui couvre le parcours complet, même si les tests incrémentaux ont réussi.
• Si vous devez confirmer que le message est consultable dans une boîte de réception, ajoutez un contrôle de réception séparé. Ni la sélection d’un test ni la réussite d’une assertion applicative ne suffisent à l’établir.
• Si le seul objectif est un retour rapide pendant le développement, --changed peut rester une étape de diagnostic, mais ne le présentez pas comme le compte rendu complet de validation avant publication.

Cette règle évite deux erreurs opposées : imposer toute la suite à chaque modification, ce qui réduit l’intérêt des retours incrémentaux, ou laisser un résultat rapide remplacer l’étape d’acceptation qui couvre les chemins essentiels. Le guide de Bun sur les tests décrit les options du lanceur ; la stratégie d’intégration doit être définie selon les risques de votre produit.

Troisième vérification : séparer les preuves du flux applicatif

Un test qui contrôle le contenu généré par l’application peut vérifier que le message contient le bon destinataire, le bon lien ou le bon code. Il peut aussi confirmer qu’une demande de validation conduit à la mise à jour attendue dans une base de données simulée. C’est une preuve utile sur la logique applicative, mais elle ne démontre pas nécessairement que le service d’envoi a accepté le message, qu’un serveur destinataire l’a reçu ou qu’il est lisible dans une boîte de réception.

Pour chaque cas, précisez ce que l’assertion vérifie :

• une assertion sur l’objet et le corps confirme les valeurs produites par l’application ;
• une assertion sur l’URL ou le code confirme la construction de l’élément de vérification ;
• une assertion sur l’état du compte confirme l’effet applicatif après traitement ;
• une réponse simulée du fournisseur confirme uniquement le comportement associé à cette simulation ;
• la consultation d’un message dans une adresse contrôlée fournit une preuve distincte de réception lisible.

Une simulation locale reste adaptée aux erreurs rapides et reproductibles. Elle permet d’isoler les cas où le message est mal composé, où le lien est incorrect ou où la logique de compte évolue mal. En revanche, si le système d’envoi est remplacé par un faux service pendant le test, celui-ci ne peut pas attester du comportement du système externe. Le rapport doit donc décrire la preuve au bon niveau : « le message applicatif a été construit et les assertions ont réussi » n’équivaut pas à « le message est arrivé ».

Un test bun test réussi prouve-t-il que le message de validation a été reçu ? Non, pas sans un contrôle qui observe réellement la réception. Un test unitaire ou d’intégration peut démontrer que le code a appelé un adaptateur ou produit le contenu attendu ; si aucune boîte de réception n’est consultée, il n’existe pas de preuve directe de livraison. Pour choisir une adresse en fonction de la durée de suivi nécessaire, consultez notre guide sur les adresses jetables et les adresses personnelles.

Quatrième vérification : rendre la tâche d’intégration continue explicite

Les tests incrémentaux sont utiles pour obtenir rapidement un signal local, mais le contrôle de publication doit disposer d’une tâche identifiable pour les chemins critiques. Évitez de mélanger dans une même ligne de compte rendu les résultats de --changed, ceux d’une suite complète et ceux d’un contrôle de réception : ces preuves ne répondent pas à la même question.

La tâche doit préciser la commande exécutée, la version de Bun, la révision de comparaison lorsque celle-ci influe sur la sélection, les fichiers ou cas lancés et le résultat de la tâche dédiée au courrier. Si le rapport ne nomme pas les tests exécutés, conservez une sortie plus détaillée ou ajoutez un lancement ciblé au travail d’intégration. Vérifiez aussi qu’une condition d’environnement, une configuration propre à l’agent ou l’absence de secrets ne fait pas sauter un test.

Pour les modifications qui affectent le parcours de validation, définissez un contrôle qui ne dépend pas uniquement de la liste des fichiers modifiés. Il peut s’agir d’une tâche d’intégration lancée pour chaque changement pertinent ou d’une étape obligatoire avant publication. Son périmètre doit rester lié à votre produit : il s’agit de vérifier le formulaire d’inscription, la génération et le traitement du lien ou du code, puis l’état du compte, et non de créer des comptes en masse sur des services tiers.

La documentation officielle explique le comportement du lanceur, mais l’équipe doit définir les preuves exigées avant livraison. Les options de configuration de bun test peuvent aider à contrôler la découverte et l’exécution ; elles ne déterminent pas le niveau de régression requis. Un rapport clair peut donc distinguer les tests sélectionnés par --changed, l’intégration du parcours et, si nécessaire, le message consulté dans l’adresse de contrôle.

Cinquième vérification : confirmer la réception sans surinterpréter le résultat

Lorsqu’il faut vérifier que le message est réellement consultable, utilisez une adresse de réception isolée et contrôlée, réservée aux tests de votre propre produit ou à un environnement autorisé. Associez le message à l’exécution concernée grâce à des données de test identifiables, sans y placer de renseignements personnels réels. Vérifiez le destinataire, le contenu, le lien ou le code attendu, puis l’effet du clic ou de la saisie sur le compte de test.

Cette étape ne garantit pas la livraison générale. Elle atteste seulement ce qui a été observé pendant cette exécution, avec cette configuration et cette adresse. Un message lisible ne prouve pas que tous les fournisseurs, boîtes ou chemins de production se comporteront de la même façon. À l’inverse, l’absence d’un message dans la boîte ne suffit pas à localiser la cause : distinguez l’appel du service d’envoi, sa réponse, les journaux disponibles et l’état de l’adresse de contrôle.

Pour limiter les risques liés aux données, évitez d’utiliser l’adresse personnelle d’un membre de l’équipe ou des identifiants réels dans les environnements de démonstration. Notre article sur les données de test et les notifications complète cette démarche en aidant à limiter les renseignements personnels exposés pendant les essais.

Le choix final : retour rapide ou preuve de publication

--changed sert à accélérer une vérification fondée sur les changements observés ; une tâche d’intégration explicite confirme que le parcours applicatif prévu a été exécuté ; une boîte contrôlée permet d’établir séparément que le message est consultable. Ne remplacez pas l’une de ces preuves par une autre.

Si les tests concernés ont été sélectionnés, leurs assertions ont réussi et la tâche d’intégration couvre le parcours modifié, vous disposez d’éléments sur le comportement applicatif. Si vous devez aussi confirmer la réception, ajoutez un contrôle qui observe cette réception et consignez ce qui a été constaté, sans le présenter comme une garantie universelle. Si la sélection ne peut pas être démontrée, lancez les tests ciblés avant de conclure, même lorsque la commande incrémentale se termine sans erreur.

Pour un essai ponctuel du parcours de votre propre produit, Inboxonce peut fournir une adresse de réception distincte, afin de ne pas exposer votre boîte principale aux messages de test. Une adresse temporaire ne remplace ni les assertions automatisées ni les méthodes de récupération d’un compte important, qui exigent un suivi durable. Lorsque la question restante est simplement de savoir si un message de validation est lisible dans une boîte isolée, vous pouvez ouvrir Inboxonce et vérifier ce point séparément du rapport de bun test.