Avant d'écrire votre premier test, une question se pose : comment s'assurer qu'une application fonctionne correctement au fil de son évolution ?
Imaginez que votre équipe ajoute une nouvelle fonctionnalité permettant aux utilisateurs de partager leurs tâches. Tout semble fonctionner aujourd'hui. Mais que se passera-t-il dans trois semaines lorsqu'un autre développeur modifiera le système d'authentification ? Une fonctionnalité apparemment sans lien pourrait cesser de fonctionner sans que personne ne s'en aperçoive.
C'est précisément le rôle des tests automatisés. Ils permettent de vérifier qu'une application continue à répondre aux attentes, même lorsque le code évolue.
Dans ce chapitre, vous allez découvrir les différents niveaux de test utilisés dans une application full-stack moderne. Vous comprendrez également pourquoi Vitest a été choisi comme outil principal pour tester la partie back-end de notre projet. Enfin, vous installerez et configurerez votre environnement de test afin d'être prêt à écrire vos premiers scénarios de validation.
Lorsque l'on parle de tests automatisés, il est tentant de penser qu'il existe une seule manière de tester une application. En réalité, plusieurs niveaux de test coexistent, chacun répondant à un besoin spécifique.
Le premier niveau est le test unitaire. Son objectif est de vérifier le comportement d'une fonction isolée. Par exemple, imaginons une fonction chargée de hacher un mot de passe avant son stockage en base de données. Un test unitaire vérifiera uniquement cette fonction, indépendamment du reste de l'application.
Le deuxième niveau est le test d'intégration back-end. Cette fois, nous ne testons plus une fonction isolée mais une route API complète. Par exemple, nous pouvons vérifier que la routePOST /api/auth/loginrenvoie bien un jeton d'authentification lorsqu'un utilisateur fournit des identifiants valides.
Le troisième niveau est le test de composant front-end. Il permet de vérifier qu'un composant d'interface s'affiche correctement et réagit aux actions de l'utilisateur. Imaginez un composant React affichant un formulaire d'ajout de tâche. Nous pouvons tester que la saisie d'un titre puis la soumission déclenchent bien l'action attendue.
Enfin, le quatrième niveau est le test end-to-end front-end, souvent abrégé E2E front. Il reproduit le comportement réel d'un utilisateur dans l'application. Le test ouvre l'interface, remplit les formulaires, clique sur les boutons et vérifie que l'objectif final est atteint.

Chaque niveau de test répond à une question métier différente :

Prenons maintenant l'exemple de notre application de gestion de tâches.
Un utilisateur se connecte, crée une tâche, puis la marque comme terminée. Pour vérifier que ce parcours fonctionne correctement, nous pouvons intervenir à différents endroits de l'application.
Un test unitaire pourrait vérifier une fonction chargée de hacher un mot de passe avant son stockage.
Un test d'intégration back-end pourrait vérifier que la routePOST /api/auth/loginrenvoie bien un jeton d'authentification lorsqu'un utilisateur fournit des identifiants valides.
Un test de composant front-end pourrait vérifier qu'un composant React affichant un formulaire d'ajout de tâche réagit correctement lorsque l'utilisateur saisit un titre puis soumet le formulaire.
Enfin, un test E2E front-end pourrait reproduire le parcours complet d'un utilisateur qui se connecte, crée une tâche, puis vérifie qu'elle apparaît dans sa liste.
Dans notre application fil rouge, les quatre niveaux pourraient se répartir ainsi :
Niveau de test | Question métier |
Test unitaire | Cette fonction produit-elle le bon résultat ? |
Intégration back-end | Cette route API répond-elle correctement ? |
Test de composant front-end | Ce composant s'affiche-t-il et réagit-il comme prévu ? |
E2E front-end | L'utilisateur peut-il accomplir son objectif de bout en bout ? |
Dans ce cours, nous utiliserons principalement Vitest pour les tests unitaires, les tests d'intégration back-end et les tests de composant (ces derniers avec React Testing Library). Les tests end-to-end front seront réalisés avec Playwright.
Maintenant que vous comprenez les différents niveaux de test, intéressons-nous à l'outil qui va nous accompagner dans les prochains chapitres : Vitest.
Avant tout, définissons un nouveau terme. Un test runner est un programme chargé d'exécuter les tests et d'afficher les résultats. Il ne crée pas les tests à votre place. Il se contente de les lancer, d'analyser leur résultat et de vous signaler les éventuelles erreurs.
Vitest est un test runner moderne particulièrement adapté à l'écosystème JavaScript et TypeScript. Sa principale force est son intégration native avec les modules ESM (ECMAScript Modules), le système standard d'import et d'export utilisé aujourd'hui dans les projets JavaScript modernes. Concrètement, cela signifie qu'il fonctionne naturellement avec les projets Next.js récents sans nécessiter une configuration complexe. Dans notre application de gestion de tâches, Vitest sera capable de tester :
des fonctions métier isolées ;
des services de traitement de données ;
des utilitaires ;
des route handlers de l'App Router Next.js.
D'autres outils existent également :
Outil | Point fort | Cas d'usage typique |
Vitest | Rapide et moderne | Applications Next.js et Vite |
Jest | Standard historique | Projets existants et écosystèmes variés |
Mocha | Très flexible | Configurations personnalisées |
Jasmine | Solution complète historique | Applications anciennes |
Pourquoi avoir choisi Vitest pour ce cours ?
La raison est simple : il s'intègre naturellement à notre pile technologique. Nous pouvons ainsi nous concentrer sur l'apprentissage des tests plutôt que sur la configuration de l'outillage.
Mais attention : connaître Vitest ne signifie pas encore savoir tester.
C'est un peu comme posséder un thermomètre. L'outil permet de mesurer la température, mais il ne vous apprend pas à interpréter les résultats. Dans les prochains chapitres, vous apprendrez justement à construire des tests pertinents, lisibles et utiles pour votre équipe.
Passons maintenant à la pratique.
Votre tech lead vous a confié le dépôt Git de l'application de gestion de tâches. Aucun test n'est encore présent. Votre mission consiste à préparer l'environnement.
Avant de suivre les étapes en autonomie, observez dans ce screencast comment installer Vitest, créer une configuration minimale et vérifier que l’environnement fonctionne avec un premier test simple.
À vous maintenant de reproduire ces étapes dans le projet.
La première étape est l'installation des dépendances nécessaires :
npm install -D vitest jsdomChaque package joue un rôle précis :
vitestexécute les tests ;
jsdomsimule un navigateur dans l'environnement de test.
Une fois l'installation terminée, vous devez créer une configuration minimale dans le fichiervitest.config.ts.
Cette configuration permet notamment :
d'utiliser l'environnementjsdom;
d'aligner les alias de chemin avec ceux définis danstsconfig.json.
import { defineConfig } from "vitest/config"
import { fileURLToPath } from "node:url"
export default defineConfig({
test: {
environment: "jsdom",
globals: true,
},
resolve: {
alias: {
"@": fileURLToPath(new URL("./", import.meta.url)),
},
},
})Il faut ensuite ajouter deux scripts dans le fichierpackage.json:
{
"scripts": {
"test": "vitest",
"test:run": "vitest run"
}
}Quelle différence entre les deux ?
La commandenpm run testlance Vitest en mode surveillance. Les tests sont relancés automatiquement lorsque vous modifiez un fichier.
La commandenpm run test:runexécute les tests une seule fois. Elle est particulièrement utile dans les pipelines d'intégration continue.
Essayez maintenant de lancer Vitest.
npm run testSi aucun test n'existe encore, Vitest vous indiquera simplement qu'aucun fichier de test n'a été trouvé.
Créons maintenant un premier fichier nomméhello.test.ts.
Par convention, les fichiers de test utilisent généralement les suffixes :
.test.ts
.spec.ts
À l'intérieur de ce fichier, vous rencontrerez trois fonctions fondamentales :
describe(): regroupe plusieurs tests ;
it()outest(): décrit un comportement attendu ;
expect(): vérifie le résultat obtenu.
Voici un exemple minimal :
import { describe, it, expect } from "vitest";
describe("addition", () => {
it("should add two numbers", () => {
expect(1 + 1).toBe(2);
});
});
Vous venez d'intégrer l'équipe qui développe l'application de gestion de tâches servant de fil rouge à cette formation.
Votre tech lead vous a confié une première mission : préparer l'environnement de test qui sera utilisé tout au long du projet.
Pour cela, vous devez :
Installer Vitest dans le projet ;
Ajouter le scripttestdans le fichierpackage.json;
Créer un fichierhello.test.ts;
Écrire un test vérifiant queadd(1, 2)retourne bien3;
Lancer Vitest et obtenir un test vert.
Prenez quelques minutes pour réaliser ces étapes avant de consulter la correction.
Une application full-stack s'appuie sur plusieurs niveaux de test : unitaire, intégration back-end, composant front-end et end-to-end front-end.
Chaque niveau de test vérifie un objectif différent et complète les autres.
Vitest est un test runner moderne particulièrement adapté aux projets Next.js et TypeScript.
Un fichier de test utilise généralement la convention.test.tsou.spec.tset repose sur les fonctionsdescribe,itetexpect.
Vérifier son environnement avec un test simple est une bonne pratique avant d'écrire des tests métier plus complexes.
Vous savez maintenant où se situe Vitest dans la stratégie globale de test d'une application. Dans le prochain chapitre, vous écrirez vos premiers véritables tests unitaires afin de sécuriser la logique métier de l'application de gestion de tâches.