Skip to content

bun test prend en charge différents formats de sortie via des reporters. Ce document couvre à la fois les reporters intégrés et comment implémenter vos propres reporters personnalisés.


Reporters intégrés

Reporter de console par défaut

Par défaut, bun test affiche les résultats dans la console dans un format lisible :

sh
test/package-json-lint.test.ts:
 test/package.json [0.88ms]
 test/js/third_party/grpc-js/package.json [0.18ms]
 test/js/third_party/svelte/package.json [0.21ms]
 test/js/third_party/express/package.json [1.05ms]

 4 pass
 0 fail
 4 expect() calls
Ran 4 tests in 1.44ms

Lorsqu'un terminal ne prend pas en charge les couleurs, la sortie évite les caractères non-ascii :

sh
test/package-json-lint.test.ts:
(pass) test/package.json [0.48ms]
(pass) test/js/third_party/grpc-js/package.json [0.10ms]
(pass) test/js/third_party/svelte/package.json [0.04ms]
(pass) test/js/third_party/express/package.json [0.04ms]

 4 pass
 0 fail
 4 expect() calls
Ran 4 tests across 1 files. [0.66ms]

Reporter Dots

Le reporter dots affiche . pour les tests réussis et F pour les échecs—utile pour les grandes suites de tests.

sh
bun test --dots
bun test --reporter=dots

Reporter XML JUnit

Pour les environnements CI/CD, Bun prend en charge la génération de rapports XML JUnit. XML JUnit est un format largement adopté pour les résultats de tests qui peut être analysé par de nombreux systèmes CI/CD, y compris GitLab, Jenkins et d'autres.

Utiliser le reporter JUnit

Pour générer un rapport XML JUnit, utilisez le drapeau --reporter=junit avec --reporter-outfile pour spécifier le fichier de sortie :

sh
bun test --reporter=junit --reporter-outfile=./junit.xml

Cela continue à sortir vers la console comme d'habitude tout en écrivant également le rapport XML JUnit dans le chemin spécifié à la fin de l'exécution des tests.

Configuration via bunfig.toml

Vous pouvez également configurer le reporter JUnit dans votre fichier bunfig.toml :

toml
[test.reporter]
junit = "path/to/junit.xml"  # Chemin de sortie pour le rapport XML JUnit

Variables d'environnement dans les rapports JUnit

Le reporter JUnit inclut automatiquement les informations d'environnement comme <properties> dans la sortie XML. Cela peut être utile pour suivre les exécutions de tests dans les environnements CI.

Spécifiquement, il inclut les variables d'environnement suivantes lorsqu'elles sont disponibles :

Variable d'environnementNom de propriétéDescription
GITHUB_RUN_ID, GITHUB_SERVER_URL, GITHUB_REPOSITORY, CI_JOB_URLciInformations de build CI
GITHUB_SHA, CI_COMMIT_SHA, GIT_SHAcommitIdentifiants de commit Git
Nom d'hôte du systèmehostnameNom d'hôte de la machine

Cela facilite le suivi de l'environnement et du commit pour lesquels une exécution de test particulière a été effectuée.

Limitations actuelles

Le reporter JUnit présente actuellement quelques limitations qui seront abordées dans les futures mises à jour :

  • Les sorties stdout et stderr des tests individuels ne sont pas incluses dans le rapport
  • Les champs d'horodatage précis par cas de test ne sont pas inclus

Reporter GitHub Actions

Bun test détecte automatiquement lorsqu'il s'exécute dans GitHub Actions et émet des annotations GitHub Actions directement dans la console. Aucune configuration spéciale n'est nécessaire au-delà de l'installation de Bun et de l'exécution de bun test.

Pour un exemple de configuration de workflow GitHub Actions, consultez la section intégration CI/CD de la documentation CLI.


Reporters personnalisés

Bun permet aux développeurs d'implémenter des reporters de tests personnalisés en étendant le protocole Inspector WebKit avec des domaines de test supplémentaires spécifiques.

Protocole Inspector pour les tests

Pour prendre en charge le reporting de tests, Bun étend le protocole Inspector WebKit standard avec deux domaines personnalisés :

  1. TestReporter : Signale la découverte des tests, le début d'exécution et les événements de fin
  2. LifecycleReporter : Signale les erreurs et exceptions pendant l'exécution des tests

Ces extensions vous permettent de créer des outils de reporting personnalisés qui peuvent recevoir des informations détaillées sur l'exécution des tests en temps réel.

Événements clés

Les reporters personnalisés peuvent écouter ces événements clés :

  • TestReporter.found : Émis lorsqu'un test est découvert
  • TestReporter.start : Émis lorsqu'un test commence à s'exécuter
  • TestReporter.end : Émis lorsqu'un test se termine
  • Console.messageAdded : Émis lorsqu'une sortie console se produit pendant un test
  • LifecycleReporter.error : Émis lorsqu'une erreur ou exception se produit

Bun édité par www.bunjs.com.cn