Tests

elide test führt node:test-Dateien in JavaScript und TypeScript sowie JUnit-Tests aus.

elide test

Ein fehlschlagender Test führt zu einem Exit-Code ungleich null.

JavaScript und TypeScript

Tests verwenden die node:test-API und brauchen kein Manifest. Eine Datei ist ein Test, wenn sie auf *.test.*, *.spec.*, *_test.* oder *_spec.* passt oder unter test, tests oder __tests__ liegt. Endungen: .js, .mjs, .cjs, .ts, .mts, .cts.

Die Erkennung überspringt versteckte Verzeichnisse, Abhängigkeits- und Build-Ausgabeverzeichnisse. Sie hält bei jedem verschachtelten Projekt an (einem Verzeichnis mit elide.pkl, package.json, pom.xml oder requirements.txt), daher findet ein Workspace-Wurzelverzeichnis keine Tests der Mitglieder. Geben Sie einen Pfad an, um sie auszuführen.

import test from "node:test";
import assert from "node:assert";

test("adds two values", () => {
  assert.equal(1 + 1, 2);
});

JVM-Tests

JVM-Tests laufen auf der JUnit Platform und brauchen eine elide.pkl. src/test ist das Standard-Source-Set für Tests; ein deklariertes Source-Set vom Typ test ersetzt es (Source-Sets).

• Test-Sets erhalten testPackages plus die Abhängigkeiten des Haupt-Sets.
• Mitgelieferte JUnit-Bibliotheken werden standardmäßig hinzugefügt. jvm.features.testing = false entfernt sowohl die JUnit-APIs zum Kompilieren als auch die mitgelieferte Laufzeit; ein JVM-Testlauf braucht dann einen JUnit-Konsolen-Launcher (junit-platform-console) in testPackages und schlägt sonst mit einem Fehler fehl. Läufe ohne JVM-Tests sind nicht betroffen.
• processors laufen auf den Testquellen.
• Die Test-JVM erhält jvm.flags und jvm.defs (als -D).
• modules-Abhängigkeiten des Test- und des Haupt-Sets kommen mit --add-modules=ALL-MODULE-PATH auf --module-path.
• Parallelitätseinstellungen in einer junit-platform.properties auf dem Test-Classpath überschreiben --concurrency.

Tests auswählen

Pfade, Verzeichnisse oder Globs grenzen JavaScript- und TypeScript-Tests ein:

elide test src/api
elide test src/api/client.test.ts

Pfadargumente überspringen JVM-Tests und geben Path filtering unsupported for JVM tests: <paths> aus. -t filtert in beiden Test-Runnern nach Testnamen:

elide test -t 'parses .+ headers'

JVM-Tests akzeptieren JUnit-Selektoren und Tag-Ausdrücke:

elide test --select=class:com.example.ParserTest
elide test --select=method:com.example.ParserTest#parsesHeaders
elide test --select=package:com.example.parser   # the package and its subpackages
elide test com.example.parser                     # a dotted bare token is a package selector
elide test --include-tag=fast --include-tag=unit  # fast OR unit
elide test --exclude-tag=slow --exclude-tag=flaky # neither slow nor flaky
elide build test --select=class:com.example.ParserTest

--include-tag='slow & !flaky' ist ein einziger Ausdruck. Tag-Filter greifen nach den Selektoren.

Ausgabe und Berichte

Der Fortschritt geht nach stderr, die abschließende Bilanz nach stdout:

elide test > summary.txt
elide test 2> progress.txt

Reporter schreiben nach .dev/reports/tests/<language>/<source-set>/. testing.reports in elide.pkl aktiviert sie ohne Flag:

import "elide:Testing.pkl" as Testing

testing {
  reports { Testing.xmlReport() }
}

TAP-Ausgabe

--reporter=tap macht stdout zu einem reinen TAP-13-Stream:

TAP version 13
# start 1: suite A > t1
# out 1: printed from inside a test
ok 1 - suite A > t1
# start 2: broken
not ok 2 - broken
  ---
  message: "expected 1 to equal 2"
  severity: "ERR_ASSERTION"
  ...
1..2

• # start <id> eröffnet einen Test; seine Ausgabezeilen lauten # out <id>: <text>. # out: <text> gehört zu keinem Test.
• Testpunkte sind in der Reihenfolge ihres Abschlusses von 1..N nummeriert. Ordnen Sie Punkte über die # start-Zeile den Tests zu, nicht über die Nummer.
• Ein YAML-Block erscheint nur bei Fehlschlägen mit Details; severity ist der Fehlercode des Runners, falls vorhanden.
• Stderr wird nicht eingerahmt: elide test --reporter=tap 2>&1 ist kein gültiges TAP.
• JVM: Ausgabe wird ihrem Test nur zugeordnet, solange genau ein Test läuft. Mit --concurrency über 1 oder einer junit-platform.properties im Projekt bleibt sie ohne Zuordnung.
• JavaScript: console.log in einem Test oder auf oberster Ebene nach dem Import von node:test wird eingerahmt. Ausgabe vor diesem Import ist roh. Hook-Ausgabe gehört zu dem Test, den der Hook umschließt; t.diagnostic wird als # out eingerahmt.

Abdeckung

elide test --coverage
elide run --coverage

JVM-Abdeckung landet als HTML, XML oder CSV in .dev/reports/coverage/jvm/<task>/; die Abdeckung für JavaScript und TypeScript ist LCOV, in .dev/reports/coverage/js/lcov.info für Tests und .dev/reports/coverage/js/run/lcov.info für Läufe. Die Konsole gibt eine gemeinsame Zusammenfassung aus. Der Block coverage auf oberster Ebene erfasst ohne das Flag:

import "elide:Coverage.pkl" as Coverage

coverage {
  enabled = true
  scope = "tests"
  jvm {
    excludes { "org.example.generated.*" }
    reports {
      Coverage.xmlReport()
      Coverage.htmlReport()
    }
  }
  js {
    paths { "src" }
  }
}

Mit Abdeckung startet elide run einen separaten JVM-Prozess.

Optionen

Syntax: Debugging. Eine unbekannte Option oder ein fehlender Wert schlägt fehl, bevor etwas läuft (Build-Tasks).

Einschränkungen

• Keine Erkennung von Python-Tests; führen Sie stattdessen unittest oder pytest aus (Python-Tests).
• JVM-Tests brauchen ein Manifest.
• Nicht implementiert: node:test-Snapshots, mock.module, Watch-Modus, programmatisches run(), node:test/reporters.

Unterstützte API: Node-Test-API.

Beispiele

• TypeScript-Tests
• Kotlin-Tests
• Tests mit CEL filtern
• JUnit-XML in CI

Mit einer Vorlage beginnen:

elide init --template java        # Java app with a JUnit test
elide init --template ktjvm       # Kotlin app with a test