Configurez bun test via le fichier bunfig.toml et les options en ligne de commande. Cette page documente les options de configuration disponibles pour bun test.

Fichier de configuration

Vous pouvez configurer le comportement de bun test en ajoutant une section [test] à votre fichier bunfig.toml :

[test]
# Les options vont ici

Découverte des tests

root

L'option root spécifie un répertoire racine pour la découverte des tests, remplaçant le comportement par défaut de balayage depuis la racine du projet.

[test]
root = "src"  # Balayer uniquement les tests dans le répertoire src

Ceci est utile lorsque vous voulez :

• Limiter la découverte des tests à des répertoires spécifiques
• Exclure certaines parties de votre projet du balayage des tests
• Organiser les tests dans une structure de sous-répertoires spécifique

Exemples

[test]
# Exécuter uniquement les tests dans le répertoire src
root = "src"

# Exécuter les tests dans un répertoire de test spécifique
root = "tests"

# Exécuter les tests dans plusieurs répertoires spécifiques (non pris en charge actuellement - utilisez plutôt les motifs)
# root = ["src", "lib"]  # Cette syntaxe n'est pas prise en charge

Scripts de préchargement

Chargez des scripts avant d'exécuter les tests en utilisant l'option preload :

[test]
preload = ["./test-setup.ts", "./global-mocks.ts"]

Ceci est équivalent à l'utilisation de --preload en ligne de commande :

bun test --preload ./test-setup.ts --preload ./global-mocks.ts

Cas d'utilisation courants des scripts de préchargement

// Configuration globale des tests
import { beforeAll, afterAll } from "bun:test";

beforeAll(() => {
  // Configurer la base de données de test
  setupTestDatabase();
});

afterAll(() => {
  // Nettoyer
  cleanupTestDatabase();
});

// Mocks globaux
import { mock } from "bun:test";

// Mock des variables d'environnement
process.env.NODE_ENV = "test";
process.env.API_URL = "http://localhost:3001";

// Mock des dépendances externes
mock.module("./external-api", () => ({
  fetchData: mock(() => Promise.resolve({ data: "test" })),
}));

Timeouts

Timeout par défaut

Définissez le timeout par défaut pour tous les tests :

[test]
timeout = 10000  # 10 secondes (par défaut 5000ms)

Ceci s'applique à tous les tests sauf s'il est remplacé par des timeouts individuels :

// Ce test utilisera le timeout par défaut de bunfig.toml
test("utilise le timeout par défaut", () => {
  // implémentation du test
});

// Ce test remplace le timeout par défaut
test("timeout personnalisé", () => {
  // implémentation du test
}, 30000); // 30 secondes

Reporters

Reporter JUnit

Configurez le chemin de sortie du reporter JUnit directement dans le fichier de configuration :

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

Ceci complète les drapeaux CLI --reporter=junit et --reporter-outfile :

# Utilisation en ligne de commande équivalente
bun test --reporter=junit --reporter-outfile=./junit.xml

Plusieurs reporters

Vous pouvez utiliser plusieurs reporters simultanément :

# Approche CLI
bun test --reporter=junit --reporter-outfile=./junit.xml

# Approche fichier de configuration

[test.reporter]
junit = "./reports/junit.xml"

[test]
# Activer également le reporting de couverture
coverage = true
coverageReporter = ["text", "lcov"]

Utilisation de la mémoire

Mode smol

Activez le mode d'économie de mémoire --smol spécifiquement pour le runner de tests :

[test]
smol = true  # Réduire l'utilisation de la mémoire pendant l'exécution des tests

Ceci est équivalent à l'utilisation du drapeau --smol en ligne de commande :

bun test --smol

Le mode smol réduit l'utilisation de la mémoire en :

• Utilisant moins de mémoire pour le tas JavaScript
• Étant plus agressif sur le garbage collection
• Réduisant les tailles de tampon lorsque possible

Ceci est utile pour :

• Les environnements CI avec mémoire limitée
• Les grandes suites de tests qui consomment beaucoup de mémoire
• Les environnements de développement avec contraintes de mémoire

Exécution des tests

concurrentTestGlob

Exécutez automatiquement les fichiers de test correspondant à un motif glob avec l'exécution concurrente des tests activée. Ceci est utile pour migrer progressivement les suites de tests vers l'exécution concurrente ou pour exécuter des types de tests spécifiques de manière concurrente.

[test]
concurrentTestGlob = "**/concurrent-*.test.ts"  # Exécuter les fichiers correspondant à ce motif de manière concurrente

Les fichiers de test correspondant à ce motif se comporteront comme si le drapeau --concurrent avait été passé, exécutant tous les tests dans ces fichiers de manière concurrente. Cela vous permet de :

• Migrer progressivement votre suite de tests vers l'exécution concurrente
• Exécuter les tests d'intégration de manière concurrente tout en gardant les tests unitaires séquentiels
• Séparer les tests rapides concurrents des tests qui nécessitent une exécution séquentielle

Le drapeau CLI --concurrent remplacera ce paramètre lorsqu'il est spécifié, forçant tous les tests à s'exécuter de manière concurrente quel que soit le motif glob.

randomize

Exécutez les tests dans un ordre aléatoire pour identifier les tests avec des dépendances cachées :

[test]
randomize = true

seed

Spécifiez une seed pour un ordre de test aléatoire reproductible. Nécessite randomize = true :

[test]
randomize = true
seed = 2444615283

rerunEach

Ré-exécutez chaque fichier de test plusieurs fois pour identifier les tests instables :

[test]
rerunEach = 3

Options de couverture

Paramètres de couverture de base

[test]
# Activer la couverture par défaut
coverage = true

# Définir le reporter de couverture
coverageReporter = ["text", "lcov"]

# Définir le répertoire de sortie de couverture
coverageDir = "./coverage"

Ignorer les fichiers de test dans la couverture

Exclure les fichiers correspondant aux motifs de test (par exemple *.test.ts) du rapport de couverture :

[test]
coverageSkipTestFiles = true  # Exclure les fichiers de test des rapports de couverture

Seuils de couverture

Le seuil de couverture peut être spécifié soit comme un nombre, soit comme un objet avec des seuils spécifiques :

[test]
# Seuil simple - s'applique aux lignes, fonctions et instructions
coverageThreshold = 0.8

# Seuils détaillés
coverageThreshold = { lines = 0.9, functions = 0.8, statements = 0.85 }

La définition de l'un de ces seuils active fail_on_low_coverage, ce qui fait échouer l'exécution des tests si la couverture est inférieure au seuil.

Exemples de seuils

[test]
# Exiger 90% de couverture partout
coverageThreshold = 0.9

# Différentes exigences pour différentes métriques
coverageThreshold = {
  lines = 0.85,      # 85% de couverture des lignes
  functions = 0.90,  # 90% de couverture des fonctions
  statements = 0.80  # 80% de couverture des instructions
}

Motifs d'ignorance de chemin de couverture

Exclure des fichiers spécifiques ou des motifs de fichiers des rapports de couverture en utilisant des motifs glob :

[test]
# Motif unique
coveragePathIgnorePatterns = "**/*.spec.ts"

# Plusieurs motifs
coveragePathIgnorePatterns = [
  "**/*.spec.ts",
  "**/*.test.ts",
  "src/utils/**",
  "*.config.js",
  "generated/**",
  "vendor/**"
]

Les fichiers correspondant à l'un de ces motifs seront exclus du calcul et du reporting de couverture. Consultez la documentation sur la couverture pour plus de détails et d'exemples.

Motifs d'ignorance courants

[test]
coveragePathIgnorePatterns = [
  # Fichiers de test
  "**/*.test.ts",
  "**/*.spec.ts",
  "**/*.e2e.ts",

  # Fichiers de configuration
  "*.config.js",
  "*.config.ts",
  "webpack.config.*",
  "vite.config.*",

  # Sortie de build
  "dist/**",
  "build/**",
  ".next/**",

  # Code généré
  "generated/**",
  "**/*.generated.ts",

  # Vendor/tiers
  "vendor/**",
  "third-party/**",

  # Utilitaires qui n'ont pas besoin d'être testés
  "src/utils/constants.ts",
  "src/types/**"
]

Gestion des sourcemaps

En interne, Bun transpile chaque fichier. Cela signifie que la couverture de code doit également passer par les sourcemaps avant de pouvoir être reportée. Nous exposons cela comme un drapeau pour vous permettre de vous exclure de ce comportement, mais ce sera confus car pendant le processus de transpilation, Bun peut déplacer du code et changer les noms de variables. Cette option est surtout utile pour déboguer les problèmes de couverture.

[test]
coverageIgnoreSourcemaps = true  # Ne pas utiliser les sourcemaps pour l'analyse de couverture

Héritage des paramètres d'installation

La commande bun test hérite de la configuration réseau et d'installation pertinente (registry, cafile, prefer, exact, etc.) de la section [install] de bunfig.toml. Ceci est important si les tests doivent interagir avec des registres privés ou nécessitent des comportements d'installation spécifiques déclenchés pendant l'exécution des tests.

[install]
# Ces paramètres sont hérités par bun test
registry = "https://npm.company.com/"
exact = true
prefer = "offline"

[test]
# Configuration spécifique aux tests
coverage = true
timeout = 10000

Variables d'environnement

Vous pouvez également définir des variables d'environnement dans votre configuration qui affectent le comportement des tests :

[env]
NODE_ENV = "test"
DATABASE_URL = "postgresql://localhost:5432/test_db"
LOG_LEVEL = "error"

[test]
coverage = true

Exemple de configuration complète

Voici un exemple complet montrant toutes les options de configuration de test disponibles :

[install]
# Paramètres d'installation hérités par les tests
registry = "https://registry.npmjs.org/"
exact = true

[env]
# Variables d'environnement pour les tests
NODE_ENV = "test"
DATABASE_URL = "postgresql://localhost:5432/test_db"
API_URL = "http://localhost:3001"
LOG_LEVEL = "error"

[test]
# Découverte des tests
root = "src"
preload = ["./test-setup.ts", "./global-mocks.ts"]

# Paramètres d'exécution
timeout = 10000
smol = true

# Configuration de la couverture
coverage = true
coverageReporter = ["text", "lcov"]
coverageDir = "./coverage"
coverageThreshold = { lines = 0.85, functions = 0.90, statements = 0.80 }
coverageSkipTestFiles = true
coveragePathIgnorePatterns = [
  "**/*.spec.ts",
  "src/utils/**",
  "*.config.js",
  "generated/**"
]

# Paramètres de couverture avancés
coverageIgnoreSourcemaps = false

# Configuration du reporter
[test.reporter]
junit = "./reports/junit.xml"

Comportement de remplacement CLI

Les options en ligne de commande remplacent toujours les paramètres du fichier de configuration :

[test]
timeout = 5000
coverage = false

# Ces drapeaux CLI remplacent le fichier de configuration
bun test --timeout 10000 --coverage
# le timeout sera de 10000ms et la couverture sera activée

Configuration conditionnelle

Vous pouvez utiliser différentes configurations pour différents environnements :

[test]
# Configuration de test par défaut
coverage = false
timeout = 5000

# Remplacement pour l'environnement CI
[test.ci]
coverage = true
coverageThreshold = 0.8
timeout = 30000

Puis en CI :

# Utiliser les paramètres spécifiques CI
bun test --config=ci

Validation et dépannage

Configuration invalide

Bun vous avertira des options de configuration invalides :

[test]
invalidOption = true  # Cela générera un avertissement

Problèmes de configuration courants

1. Résolution de chemin : Les chemins relatifs dans la config sont résolus par rapport à l'emplacement du fichier de configuration
2. Correspondance de motif : Les motifs glob utilisent la syntaxe glob standard
3. Incompatibilités de type : Assurez-vous que les valeurs numériques ne sont pas entre guillemets sauf si elles doivent être des chaînes

[test]
# Correct
timeout = 10000

# Incorrect - sera traité comme une chaîne
timeout = "10000"

Débogage de la configuration

Pour voir quelle configuration est utilisée :

# Afficher la configuration effective
bun test --dry-run

# Sortie verbose pour voir le chargement de la configuration
bun test --verbose