Tests

elide test exécute des fichiers node:test JavaScript et TypeScript et des tests JUnit.

elide test

Un test en échec rend le code de sortie non nul.

JavaScript et TypeScript

Les tests utilisent l’API node:test et n’ont pas besoin de manifeste. Un fichier est un test s’il correspond à *.test.*, *.spec.*, *_test.* ou *_spec.*, ou s’il se trouve sous test, tests ou __tests__. Extensions : .js, .mjs, .cjs, .ts, .mts, .cts.

La découverte ignore les répertoires cachés, de dépendances et de sortie de build. Elle s’arrête à tout projet imbriqué (un répertoire contenant elide.pkl, package.json, pom.xml ou requirements.txt) : la racine d’un espace de travail ne trouve donc pas les tests des membres. Indiquez un chemin pour les exécuter.

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

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

Tests JVM

Les tests JVM s’exécutent sur la JUnit Platform et nécessitent un elide.pkl. src/test est le source set de test par défaut ; un source set déclaré de type test le remplace (Source sets).

• Les source sets de test reçoivent testPackages ainsi que les dépendances du source set principal.
• Les bibliothèques JUnit fournies sont ajoutées par défaut. jvm.features.testing = false retire à la fois les API JUnit de compilation et l’environnement d’exécution fourni ; une exécution de tests JVM a alors besoin d’un lanceur console JUnit (junit-platform-console) dans testPackages, et échoue avec une erreur sinon. Les exécutions sans tests JVM ne sont pas concernées.
• Les processors s’exécutent sur les sources de test.
• La JVM de test reçoit jvm.flags et jvm.defs (sous forme de -D).
• Les dépendances modules des source sets de test et principal vont sur --module-path avec --add-modules=ALL-MODULE-PATH.
• Les réglages de parallélisme d’un junit-platform.properties présent sur le classpath de test remplacent --concurrency.

Sélectionner des tests

Des chemins, répertoires ou globs restreignent les tests JavaScript et TypeScript :

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

Les arguments de chemin ignorent les tests JVM et affichent Path filtering unsupported for JVM tests: <paths>. -t filtre sur le nom des tests dans les deux exécuteurs :

elide test -t 'parses .+ headers'

Les tests JVM acceptent les sélecteurs JUnit et les expressions de tags :

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' est une seule expression. Les filtres de tags s’appliquent après les sélecteurs.

Sortie et rapports

La progression va sur stderr ; le bilan final sur stdout :

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

Les rapports sont écrits dans .dev/reports/tests/<language>/<source-set>/. testing.reports dans elide.pkl les active sans option :

import "elide:Testing.pkl" as Testing

testing {
  reports { Testing.xmlReport() }
}

Sortie TAP

--reporter=tap fait de stdout un flux TAP 13 pur :

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> ouvre un test ; ses lignes de sortie sont # out <id>: <text>. # out: <text> n’appartient à aucun test.
• Les points de test sont numérotés 1..N dans l’ordre où ils se terminent. Associez les points aux tests par la ligne # start, pas par le numéro.
• Un bloc YAML n’apparaît qu’en cas d’échec avec des détails ; severity est le code d’erreur de l’exécuteur, s’il existe.
• Stderr n’est pas encapsulé : elide test --reporter=tap 2>&1 n’est pas du TAP valide.
• JVM : la sortie n’est rattachée à son test que tant qu’un seul test s’exécute. Avec --concurrency supérieur à 1 ou un junit-platform.properties dans le projet, elle n’est rattachée à aucun test.
• JavaScript : console.log dans un test, ou au niveau supérieur après l’import de node:test, est encapsulé. La sortie antérieure à cet import est brute. La sortie d’un hook appartient au test qu’il entoure ; t.diagnostic est encapsulé sous forme de # out.

Couverture

elide test --coverage
elide run --coverage

La couverture JVM va dans .dev/reports/coverage/jvm/<task>/ au format HTML, XML ou CSV ; la couverture JavaScript et TypeScript est au format LCOV, dans .dev/reports/coverage/js/lcov.info pour les tests et .dev/reports/coverage/js/run/lcov.info pour les exécutions. La console affiche un seul résumé combiné. Le bloc coverage de premier niveau collecte sans l’option :

import "elide:Coverage.pkl" as Coverage

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

Avec la couverture, elide run lance un processus JVM distinct.

Options

Syntaxe : Débogage. Une option inconnue ou une valeur manquante échoue avant toute exécution (Tâches de build).

Limites

• Pas de découverte des tests Python ; exécutez plutôt unittest ou pytest (Tests Python).
• Les tests JVM nécessitent un manifeste.
• Non implémentés : les snapshots de node:test, mock.module, le mode watch, run() programmatique, node:test/reporters.

API prise en charge : API de test de Node.

Exemples

• Tests TypeScript
• Tests Kotlin
• Filtrer les tests avec CEL
• JUnit XML en CI

Partez d’un modèle :

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