Node.js : tester sans dépendance avec le test runner natif

Pendant des années, tester un projet Node.js commençait par un choix de framework : Mocha, Jest, puis Vitest. Depuis que le module node:test est stable, Node.js embarque son propre runner, avec assertions, mocks, mode watch et rapport de couverture. Pour une API, une CLI ou une librairie backend, c’est souvent tout ce dont vous avez besoin.

Ce que le runner natif apporte

Il suffit d’importer test ou describe/it depuis node:test et assert depuis node:assert/strict, puis de lancer node --test. Le runner découvre automatiquement les fichiers de test, exécute les suites en parallèle dans des processus séparés et gère nativement les fonctions asynchrones, les hooks before/afterEach, les tests ignorés ou marqués « todo ». Aucune installation, aucune configuration, aucune mise à jour de dépendance à surveiller : le runner évolue au rythme de votre version de Node.

Mocks, timers et snapshots intégrés

L’objet mock fournit des espions de fonctions et de méthodes, avec l’historique des appels et la restauration automatique à la fin du test. Les timers simulés permettent de tester un retry, un debounce ou une expiration de cache sans attendre réellement les délais. Les versions récentes ajoutent les snapshots via le contexte de test, pratiques pour figer la forme d’une réponse d’API ou d’un rendu de template. Pour le réseau, combinez ces outils avec une injection de dépendances simple : votre code reste testable sans magie de remplacement de modules.

TypeScript, watch et couverture

Les versions récentes de Node exécutent directement des fichiers TypeScript simples grâce au type stripping : vos tests .test.ts tournent sans étape de compilation, tant qu’ils évitent les fonctionnalités nécessitant une transformation (enums, namespaces). Le flag --watch relance les tests à chaque modification, et --experimental-test-coverage produit un rapport de couverture avec des seuils configurables. Gardez néanmoins tsc --noEmit dans la CI : le runner retire les types, il ne les vérifie pas.

Quand rester sur Vitest ou Jest

Le runner natif brille côté serveur, mais il n’a pas vocation à remplacer un outillage front-end. Pour tester des composants React, Vue ou Angular, simuler un DOM, profiter de l’intégration Vite ou d’un écosystème de matchers riche, Vitest reste plus confortable. Une stratégie pragmatique consiste à utiliser node:test pour les packages backend et les scripts d’un monorepo, et Vitest pour les applications front. Côté CI, les reporters TAP, spec ou JUnit s’intègrent sans effort à GitHub Actions ou GitLab.