Skip to content

Konfigurieren Sie bun test über die bunfig.toml-Datei und Befehlszeilenoptionen. Diese Seite dokumentiert die verfügbaren Konfigurationsoptionen für bun test.

Konfigurationsdatei

Sie können das Verhalten von bun test konfigurieren, indem Sie einen [test]-Abschnitt zu Ihrer bunfig.toml-Datei hinzufügen:

bunfig.toml
toml
[test]
# Optionen kommen hier

Test-Erkennung

root

Die root-Option gibt ein Root-Verzeichnis für die Test-Erkennung an und überschreibt das Standardverhalten des Scannens vom Projekt-Root.

bunfig.toml
toml
[test]
root = "src"  # Nur im src-Verzeichnis nach Tests scannen

Dies ist nützlich, wenn Sie:

  • Die Test-Erkennung auf bestimmte Verzeichnisse beschränken möchten
  • Bestimmte Teile Ihres Projekts vom Test-Scanning ausschließen möchten
  • Tests in einer bestimmten Unterverzeichnisstruktur organisieren möchten

Beispiele

bunfig.toml
toml
[test]
# Nur Tests im src-Verzeichnis ausführen
root = "src"

# Tests in einem bestimmten Test-Verzeichnis ausführen
root = "tests"

# Tests in mehreren bestimmten Verzeichnissen ausführen (derzeit nicht unterstützt - verwenden Sie stattdessen Muster)
# root = ["src", "lib"]  # Diese Syntax wird nicht unterstützt

Preload-Skripte

Laden Sie Skripte vor dem Ausführen von Tests mit der preload-Option:

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

Dies entspricht der Verwendung von --preload in der Befehlszeile:

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

Häufige Preload-Anwendungsfälle

test-setup.ts
ts
// Globales Test-Setup
import { beforeAll, afterAll } from "bun:test";

beforeAll(() => {
  // Test-Datenbank einrichten
  setupTestDatabase();
});

afterAll(() => {
  // Aufräumen
  cleanupTestDatabase();
});
global-mocks.ts
ts
// Globale Mocks
import { mock } from "bun:test";

// Umgebungsvariablen mocken
process.env.NODE_ENV = "test";
process.env.API_URL = "http://localhost:3001";

// Externe Abhängigkeiten mocken
mock.module("./external-api", () => ({
  fetchData: mock(() => Promise.resolve({ data: "test" })),
}));

Timeouts

Standard-Timeout

Legen Sie das Standard-Timeout für alle Tests fest:

bunfig.toml
toml
[test]
timeout = 10000  # 10 Sekunden (Standard ist 5000ms)

Dies gilt für alle Tests, es sei denn, es wird durch einzelne Test-Timeouts überschrieben:

test.ts
ts
// Dieser Test verwendet das Standard-Timeout aus bunfig.toml
test("verwendet Standard-Timeout", () => {
  // Test-Implementierung
});

// Dieser Test überschreibt das Standard-Timeout
test("benutzerdefiniertes Timeout", () => {
  // Test-Implementierung
}, 30000); // 30 Sekunden

Reporter

JUnit-Reporter

Konfigurieren Sie den JUnit-Reporter-Ausgabedateipfad direkt in der Konfigurationsdatei:

bunfig.toml
toml
[test.reporter]
junit = "path/to/junit.xml"  # Ausgabepfad für JUnit-XML-Bericht

Dies ergänzt die --reporter=junit- und --reporter-outfile-CLI-Flags:

bash
# Entsprechende Befehlszeilenverwendung
bun test --reporter=junit --reporter-outfile=./junit.xml

Mehrere Reporter

Sie können mehrere Reporter gleichzeitig verwenden:

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

# Konfigurationsdatei-Ansatz
bunfig.toml
toml
[test.reporter]
junit = "./reports/junit.xml"

[test]
# Coverage-Berichterstattung auch aktivieren
coverage = true
coverageReporter = ["text", "lcov"]

Speichernutzung

smol-Modus

Aktivieren Sie den --smol-Speicher-sparmodus speziell für den Test-Runner:

bunfig.toml
toml
[test]
smol = true  # Speichernutzung während Testläufen reduzieren

Dies entspricht der Verwendung des --smol-Flags in der Befehlszeile:

bash
bun test --smol

Der smol-Modus reduziert die Speichernutzung durch:

  • Weniger Speicher für den JavaScript-Heap verwenden
  • Aggressiver bei der Garbage Collection sein
  • Puffergrößen reduzieren, wo möglich

Dies ist nützlich für:

  • CI-Umgebungen mit begrenztem Speicher
  • Große Testsuiten, die erheblichen Speicher verbrauchen
  • Entwicklungsumgebungen mit Speicherbeschränkungen

Test-Ausführung

concurrentTestGlob

Führt Testdateien, die mit einem Glob-Muster übereinstimmen, automatisch mit aktivierter gleichzeitiger Test-Ausführung aus. Dies ist nützlich für die schrittweise Migration von Testsuiten zur gleichzeitigen Ausführung oder zum gleichzeitigen Ausführen bestimmter Testtypen.

bunfig.toml
toml
[test]
concurrentTestGlob = "**/concurrent-*.test.ts"  # Dateien, die mit diesem Muster übereinstimmen, gleichzeitig ausführen

Testdateien, die mit diesem Muster übereinstimmen, verhalten sich so, als ob das --concurrent-Flag übergeben wurde, wobei alle Tests innerhalb dieser Dateien gleichzeitig ausgeführt werden. Dies ermöglicht es Ihnen:

  • Ihre Testsuite schrittweise zur gleichzeitigen Ausführung zu migrieren
  • Integrationstests gleichzeitig auszuführen, während Unit-Tests sequentiell bleiben
  • Schnelle gleichzeitige Tests von Tests zu trennen, die sequentielle Ausführung erfordern

Das --concurrent-CLI-Flag überschreibt diese Einstellung bei Angabe und zwingt alle Tests zur gleichzeitigen Ausführung, unabhängig vom Glob-Muster.

randomize

Tests in zufälliger Reihenfolge ausführen, um Tests mit versteckten Abhängigkeiten zu identifizieren:

bunfig.toml
toml
[test]
randomize = true

seed

Einen Seed für reproduzierbare zufällige Test-Reihenfolge angeben. Erfordert randomize = true:

bunfig.toml
toml
[test]
randomize = true
seed = 2444615283

rerunEach

Jede Testdatei mehrmals ausführen, um flüchtige Tests zu identifizieren:

bunfig.toml
toml
[test]
rerunEach = 3

Coverage-Optionen

Grundlegende Coverage-Einstellungen

bunfig.toml
toml
[test]
# Coverage standardmäßig aktivieren
coverage = true

# Coverage-Reporter festlegen
coverageReporter = ["text", "lcov"]

# Coverage-Ausgabeverzeichnis festlegen
coverageDir = "./coverage"

Testdateien von Coverage ausschließen

Schließt Dateien, die mit Testmustern übereinstimmen (z. B. *.test.ts), vom Coverage-Bericht aus:

bunfig.toml
toml
[test]
coverageSkipTestFiles = true  # Testdateien von Coverage-Berichten ausschließen

Coverage-Schwellenwerte

Der Coverage-Schwellenwert kann entweder als Zahl oder als Objekt mit spezifischen Schwellenwerten angegeben werden:

bunfig.toml
toml
[test]
# Einfacher Schwellenwert - gilt für Zeilen, Funktionen und Anweisungen
coverageThreshold = 0.8

# Detaillierte Schwellenwerte
coverageThreshold = { lines = 0.9, functions = 0.8, statements = 0.85 }

Das Festlegen eines dieser Schwellenwerte aktiviert fail_on_low_coverage, wodurch der Testlauf fehlschlägt, wenn die Coverage unter dem Schwellenwert liegt.

Schwellenwert-Beispiele

bunfig.toml
toml
[test]
# 90% Coverage insgesamt erfordern
coverageThreshold = 0.9

# Unterschiedliche Anforderungen für verschiedene Metriken
coverageThreshold = {
  lines = 0.85,      # 85% Zeilen-Coverage
  functions = 0.90,  # 90% Funktions-Coverage
  statements = 0.80  # 80% Anweisungs-Coverage
}

Coverage-Pfad-Ignoriermuster

Schließen Sie bestimmte Dateien oder Dateimuster von Coverage-Berichten unter Verwendung von Glob-Mustern aus:

bunfig.toml
toml
[test]
# Einzelnes Muster
coveragePathIgnorePatterns = "**/*.spec.ts"

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

Dateien, die mit einem dieser Muster übereinstimmen, werden von der Coverage-Berechnung und -Berichterstattung ausgeschlossen. Weitere Informationen und Beispiele finden Sie in der Coverage-Dokumentation.

Häufige Ignoriermuster

bunfig.toml
toml
[test]
coveragePathIgnorePatterns = [
  # Testdateien
  "**/*.test.ts",
  "**/*.spec.ts",
  "**/*.e2e.ts",

  # Konfigurationsdateien
  "*.config.js",
  "*.config.ts",
  "webpack.config.*",
  "vite.config.*",

  # Build-Ausgabe
  "dist/**",
  "build/**",
  ".next/**",

  # Generierter Code
  "generated/**",
  "**/*.generated.ts",

  # Vendor/Third-Party
  "vendor/**",
  "third-party/**",

  # Utilities, die nicht getestet werden müssen
  "src/utils/constants.ts",
  "src/types/**"
]

Sourcemap-Handling

Intern transpiliert Bun jede Datei. Das bedeutet, dass Code-Coverage auch durch Sourcemaps gehen muss, bevor sie berichtet werden kann. Wir stellen dies als Flag zur Verfügung, um Ihnen zu ermöglichen, sich von diesem Verhalten abzumelden, aber es wird verwirrend sein, da Bun während des Transpilierungsprozesses Code verschieben und Variablennamen ändern kann. Diese Option ist hauptsächlich zum Debuggen von Coverage-Problemen nützlich.

bunfig.toml
toml
[test]
coverageIgnoreSourcemaps = true  # Sourcemaps nicht für Coverage-Analyse verwenden

Install-Einstellungen-Vererbung

Der bun test-Befehl erbt relevante Netzwerk- und Installationskonfiguration (Registry, cafile, prefer, exact usw.) vom [install]-Abschnitt von bunfig.toml. Dies ist wichtig, wenn Tests mit privaten Registries interagieren müssen oder spezifische Installationsverhalten erfordern, die während des Testlaufs ausgelöst werden.

bunfig.toml
toml
[install]
# Diese Einstellungen werden von bun test geerbt
registry = "https://npm.company.com/"
exact = true
prefer = "offline"

[test]
# Testspezifische Konfiguration
coverage = true
timeout = 10000

Umgebungsvariablen

Sie können auch Umgebungsvariablen in Ihrer Konfiguration festlegen, die das Testverhalten beeinflussen:

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

[test]
coverage = true

Vollständiges Konfigurationsbeispiel

Hier ist ein umfassendes Beispiel, das alle verfügbaren Test-Konfigurationsoptionen zeigt:

bunfig.toml
toml
[install]
# Install-Einstellungen, die von Tests geerbt werden
registry = "https://registry.npmjs.org/"
exact = true

[env]
# Umgebungsvariablen für Tests
NODE_ENV = "test"
DATABASE_URL = "postgresql://localhost:5432/test_db"
API_URL = "http://localhost:3001"
LOG_LEVEL = "error"

[test]
# Test-Erkennung
root = "src"
preload = ["./test-setup.ts", "./global-mocks.ts"]

# Ausführungseinstellungen
timeout = 10000
smol = true

# Coverage-Konfiguration
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/**"
]

# Erweiterte Coverage-Einstellungen
coverageIgnoreSourcemaps = false

# Reporter-Konfiguration
[test.reporter]
junit = "./reports/junit.xml"

CLI-Überschreibungsverhalten

Befehlszeilenoptionen überschreiben immer Konfigurationsdateieinstellungen:

bunfig.toml
toml
[test]
timeout = 5000
coverage = false
bash
# Diese CLI-Flags überschreiben die Konfigurationsdatei
bun test --timeout 10000 --coverage
# timeout wird 10000ms sein und coverage wird aktiviert sein

Bedingte Konfiguration

Sie können verschiedene Konfigurationen für verschiedene Umgebungen verwenden:

bunfig.toml
toml
[test]
# Standard-Testkonfiguration
coverage = false
timeout = 5000

# Überschreibung für CI-Umgebung
[test.ci]
coverage = true
coverageThreshold = 0.8
timeout = 30000

Dann in CI:

bash
# CI-spezifische Einstellungen verwenden
bun test --config=ci

Validierung und Fehlerbehebung

Ungültige Konfiguration

Bun warnt vor ungültigen Konfigurationsoptionen:

bunfig.toml
toml
[test]
invalidOption = true  # Dies erzeugt eine Warnung

Häufige Konfigurationsprobleme

  1. Pfadauflösung: Relative Pfade in der Konfiguration werden relativ zum Speicherort der Konfigurationsdatei aufgelöst
  2. Musterabgleich: Glob-Muster verwenden Standard-Glob-Syntax
  3. Typenfehler: Stellen Sie sicher, dass numerische Werte nicht in Anführungszeichen gesetzt sind, es sei denn, sie sollten Strings sein
bunfig.toml
toml
[test]
# Korrekt
timeout = 10000

# Falsch - wird als String behandelt
timeout = "10000"

Konfiguration debuggen

Um zu sehen, welche Konfiguration verwendet wird:

bash
# Effektive Konfiguration anzeigen
bun test --dry-run

# Ausführliche Ausgabe zum Anzeigen des Konfigurationsladens
bun test --verbose

Bun von www.bunjs.com.cn bearbeitet