Tester son code JavaScript : Jest, Vitest et Testing Library en 2025

Pourquoi tester son code JavaScript est devenu indispensable

En 2025, un projet JavaScript sans tests, c’est un peu comme une voiture sans freins. Ça avance, mais le premier virage serré peut être fatal.

Les chiffres parlent d’eux-mêmes : selon le rapport State of JS 2024, plus de 78 % des développeurs JavaScript déclarent écrire des tests pour leurs projets. Les entreprises qui adoptent une stratégie de test complète constatent en moyenne une réduction de 40 à 80 % des bugs en production et un gain significatif sur les temps de maintenance.

Mais face à la multitude d’outils disponibles, comment choisir ? Jest, Vitest, Testing Library, Cypress, Playwright… L’écosystème est riche, parfois déroutant. Dans cet article, nous nous concentrons sur le trio gagnant du test JavaScript moderne : Jest, Vitest et Testing Library.

Chez Lueur Externe, agence web spécialisée dans le développement depuis 2003, nous avons vu l’outillage de test évoluer considérablement. Voici notre retour d’expérience complet pour vous aider à faire les bons choix.

Jest : le vétéran incontournable

Présentation et historique

Créé par Meta (anciennement Facebook) en 2014, Jest est rapidement devenu le framework de test de référence dans l’écosystème JavaScript. Avec plus de 44 000 étoiles sur GitHub et des millions de téléchargements hebdomadaires sur npm, il reste en 2025 l’outil le plus utilisé pour les tests unitaires et d’intégration.

Jest a été conçu avec une philosophie “batteries included” : tout est intégré par défaut. Pas besoin de configurer séparément un test runner, une bibliothèque d’assertions, un outil de mocking ou un générateur de couverture de code. Tout est là, prêt à l’emploi.

Les forces de Jest

• Configuration minimale : un simple npm install --save-dev jest et vous êtes prêt à écrire vos premiers tests.
• Snapshot testing : fonctionnalité unique permettant de capturer le rendu d’un composant et de détecter toute modification inattendue.
• Mocking intégré : système de mock puissant avec jest.fn(), jest.mock() et jest.spyOn().
• Couverture de code native : rapport de couverture intégré sans outil supplémentaire.
• Exécution parallèle : les fichiers de test s’exécutent en parallèle dans des workers isolés.
• Écosystème massif : des centaines de plugins et une documentation exhaustive.

Exemple concret avec Jest

Voici un test unitaire classique avec Jest pour une fonction utilitaire :

// utils/formatPrice.js
export function formatPrice(price, currency = 'EUR') {
  if (typeof price !== 'number' || price < 0) {
    throw new Error('Le prix doit être un nombre positif');
  }
  return new Intl.NumberFormat('fr-FR', {
    style: 'currency',
    currency,
  }).format(price);
}

// __tests__/formatPrice.test.js
import { formatPrice } from '../utils/formatPrice';

describe('formatPrice', () => {
  test('formate correctement un prix en euros', () => {
    expect(formatPrice(29.99)).toBe('29,99 €');
  });

  test('formate correctement un prix en dollars', () => {
    expect(formatPrice(29.99, 'USD')).toBe('29,99 $US');
  });

  test('gère le prix zéro', () => {
    expect(formatPrice(0)).toBe('0,00 €');
  });

  test('rejette un prix négatif', () => {
    expect(() => formatPrice(-10)).toThrow('Le prix doit être un nombre positif');
  });

  test('rejette une valeur non numérique', () => {
    expect(() => formatPrice('abc')).toThrow();
  });
});

Ce type de test est la base de toute stratégie de qualité. Il valide le comportement attendu, les cas limites et la gestion des erreurs.

Les limites de Jest

Malgré sa popularité, Jest présente quelques inconvénients :

• Lenteur sur les gros projets : la transformation du code (transpilation via Babel ou ts-jest) ralentit significativement l’exécution.
• Support ESM incomplet : le support des modules ES natifs reste expérimental et parfois instable.
• Configuration complexe avec TypeScript : nécessite souvent ts-jest ou @swc/jest pour des performances acceptables.

Vitest : la nouvelle génération propulsée par Vite

Pourquoi Vitest change la donne

Lancé fin 2021 par l’équipe derrière Vite, Vitest a connu une adoption fulgurante. En 2025, il dépasse les 13 000 étoiles GitHub et est devenu le choix par défaut pour tout nouveau projet basé sur Vite, Nuxt 3 ou SvelteKit.

Son atout principal ? Il réutilise le pipeline de transformation de Vite, ce qui signifie :

• Support natif de TypeScript sans configuration supplémentaire.
• Support natif d’ESM sans hack ni flag expérimental.
• Hot Module Replacement (HMR) appliqué aux tests : seuls les tests impactés par une modification sont relancés.
• Compatibilité quasi totale avec l’API Jest : migrer est souvent aussi simple que de changer les imports.

Comparatif de performances Jest vs Vitest

Voici un comparatif basé sur des benchmarks réalisés sur un projet React de taille moyenne (~200 fichiers de test, ~800 tests) :

Critère	Jest (avec ts-jest)	Vitest	Écart
Premier lancement (cold start)	18,2 s	6,4 s	2,8× plus rapide
Re-exécution complète	14,7 s	4,1 s	3,6× plus rapide
Mode watch (re-run ciblé)	3,2 s	0,8 s	4× plus rapide
Support TypeScript natif	❌ (nécessite ts-jest)	✅	—
Support ESM natif	⚠️ Expérimental	✅	—
Interface UI intégrée	❌	✅ (Vitest UI)	—
Couverture de code	✅ (istanbul)	✅ (v8 ou istanbul)	—

Ces gains de performance ne sont pas anecdotiques. Sur un pipeline CI/CD, passer de 18 à 6 secondes sur chaque push, c’est des heures économisées chaque mois pour une équipe de développement.

Exemple concret avec Vitest

// utils/slugify.ts
export function slugify(text: string): string {
  return text
    .toLowerCase()
    .normalize('NFD')
    .replace(/[\u0300-\u036f]/g, '')
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/(^-|-$)/g, '');
}

// __tests__/slugify.test.ts
import { describe, it, expect } from 'vitest';
import { slugify } from '../utils/slugify';

describe('slugify', () => {
  it('convertit un texte simple en slug', () => {
    expect(slugify('Hello World')).toBe('hello-world');
  });

  it('gère les accents français', () => {
    expect(slugify('Création de site e-commerce')).toBe('creation-de-site-e-commerce');
  });

  it('supprime les caractères spéciaux', () => {
    expect(slugify('Prix : 29,99€ !')).toBe('prix-29-99');
  });

  it('gère les espaces multiples', () => {
    expect(slugify('  Trop   d\'espaces  ')).toBe('trop-d-espaces');
  });
});

Vous remarquerez que la syntaxe est quasi identique à Jest. C’est voulu : Vitest a été conçu pour faciliter la migration.

Testing Library : tester comme un utilisateur

La philosophie qui change tout

Testing Library n’est pas un test runner comme Jest ou Vitest. C’est une famille de bibliothèques utilitaires qui s’utilisent en complément d’un framework de test. Son créateur, Kent C. Dodds, résume sa philosophie en une phrase :

“Plus vos tests ressemblent à la façon dont votre logiciel est utilisé, plus ils vous donnent confiance.”

Concrètement, Testing Library vous pousse à :

• Sélectionner les éléments comme un utilisateur le ferait : par leur texte visible, leur rôle ARIA, leur label — jamais par leur classe CSS ou leur structure DOM interne.
• Interagir comme un utilisateur : cliquer, taper du texte, soumettre un formulaire.
• Vérifier ce que l’utilisateur voit : le texte affiché, les messages d’erreur, les changements d’état visuel.

Les déclinaisons de Testing Library

Testing Library existe pour la plupart des frameworks front-end :

• @testing-library/react : pour les composants React
• @testing-library/vue : pour Vue.js
• @testing-library/svelte : pour Svelte
• @testing-library/angular : pour Angular
• @testing-library/dom : la base, utilisable avec du JavaScript vanilla
• @testing-library/user-event : simule les interactions utilisateur de manière réaliste

Exemple complet : tester un formulaire React

Voici un exemple concret de test d’un composant React de formulaire de contact, utilisant Vitest et Testing Library :

// components/ContactForm.jsx
import { useState } from 'react';

export function ContactForm({ onSubmit }) {
  const [email, setEmail] = useState('');
  const [message, setMessage] = useState('');
  const [error, setError] = useState('');

  const handleSubmit = (e) => {
    e.preventDefault();
    if (!email.includes('@')) {
      setError('Veuillez saisir un email valide');
      return;
    }
    if (message.length < 10) {
      setError('Le message doit contenir au moins 10 caractères');
      return;
    }
    setError('');
    onSubmit({ email, message });
  };

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">Email</label>
      <input
        id="email"
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <label htmlFor="message">Message</label>
      <textarea
        id="message"
        value={message}
        onChange={(e) => setMessage(e.target.value)}
      />
      {error && <p role="alert">{error}</p>}
      <button type="submit">Envoyer</button>
    </form>
  );
}

// __tests__/ContactForm.test.jsx
import { describe, it, expect, vi } from 'vitest';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { ContactForm } from '../components/ContactForm';

describe('ContactForm', () => {
  it('affiche une erreur si l\'email est invalide', async () => {
    const user = userEvent.setup();
    render(<ContactForm onSubmit={vi.fn()} />);

    await user.type(screen.getByLabelText('Email'), 'email-invalide');
    await user.type(screen.getByLabelText('Message'), 'Un message suffisamment long');
    await user.click(screen.getByRole('button', { name: 'Envoyer' }));

    expect(screen.getByRole('alert')).toHaveTextContent(
      'Veuillez saisir un email valide'
    );
  });

  it('affiche une erreur si le message est trop court', async () => {
    const user = userEvent.setup();
    render(<ContactForm onSubmit={vi.fn()} />);

    await user.type(screen.getByLabelText('Email'), 'test@example.com');
    await user.type(screen.getByLabelText('Message'), 'Court');
    await user.click(screen.getByRole('button', { name: 'Envoyer' }));

    expect(screen.getByRole('alert')).toHaveTextContent(
      'Le message doit contenir au moins 10 caractères'
    );
  });

  it('appelle onSubmit avec les données valides', async () => {
    const user = userEvent.setup();
    const handleSubmit = vi.fn();
    render(<ContactForm onSubmit={handleSubmit} />);

    await user.type(screen.getByLabelText('Email'), 'contact@lueurexterne.com');
    await user.type(screen.getByLabelText('Message'), 'Bonjour, je souhaite un devis pour mon site.');
    await user.click(screen.getByRole('button', { name: 'Envoyer' }));

    expect(handleSubmit).toHaveBeenCalledWith({
      email: 'contact@lueurexterne.com',
      message: 'Bonjour, je souhaite un devis pour mon site.',
    });
  });
});

Notez comment chaque test décrit un scénario utilisateur concret. On ne vérifie jamais l’état interne du composant (useState), on vérifie ce qui est visible à l’écran. C’est exactement la force de Testing Library.

Quelle stratégie de test adopter ?

La pyramide des tests

La stratégie de test la plus éprouvée reste la pyramide des tests :

• Base (70 %) : Tests unitaires — rapides, isolés, nombreux. C’est le domaine de Jest/Vitest.
• Milieu (20 %) : Tests d’intégration — vérifient l’interaction entre plusieurs modules. Testing Library excelle ici.
• Sommet (10 %) : Tests end-to-end (E2E) — simulent un parcours utilisateur complet. Outils dédiés comme Playwright ou Cypress.

Comment choisir entre Jest et Vitest

Voici notre recommandation pragmatique :

• Nouveau projet avec Vite, Nuxt 3, SvelteKit ou Astro → Vitest, sans hésiter.
• Projet existant avec Create React App ou Webpack → Jest reste pertinent. Migrer vers Vitest n’est intéressant que si vous migrez aussi vers Vite.
• Projet Node.js pur (API, CLI) → Les deux fonctionnent très bien. Vitest apporte un avantage de vitesse même sans Vite.
• Projet en entreprise avec une équipe senior sur Jest → Ne migrez pas pour le principe. Migrez si la lenteur des tests devient un frein mesurable.

Les bonnes pratiques incontournables

Quel que soit l’outil choisi, certaines pratiques sont universelles :

• Un test = un comportement. Chaque test doit vérifier une seule chose précise.
• Nommez vos tests comme des spécifications : “affiche une erreur si le champ email est vide” est meilleur que “test 1”.
• Évitez les tests trop couplés à l’implémentation : si un refactoring qui ne change pas le comportement casse vos tests, c’est un mauvais signe.
• Maintenez une couverture de code raisonnable : visez 80 % plutôt que 100 %. Les derniers pourcents coûtent cher en maintenance pour un gain minimal.
• Intégrez les tests dans votre CI/CD : un test qui ne tourne pas automatiquement à chaque commit n’a presque aucune valeur.
• Moquez le strict nécessaire : trop de mocks rendent les tests fragiles et déconnectés de la réalité.

L’avenir des tests JavaScript

L’écosystème des tests JavaScript évolue rapidement. Quelques tendances à surveiller en 2025 et au-delà :

• Node.js Test Runner natif : depuis Node.js 20, un test runner est intégré directement dans Node. Encore jeune, mais prometteur pour les projets minimalistes.
• Vitest 2.x : des améliorations majeures sur le browser mode, permettant de lancer des tests directement dans un vrai navigateur plutôt que dans un environnement simulé (jsdom).
• Tests basés sur l’IA : des outils commencent à générer automatiquement des tests à partir du code source. Utile comme point de départ, mais la relecture humaine reste indispensable.
• Component testing dans Playwright et Cypress : la frontière entre tests d’intégration et tests E2E s’estompe.

L’équipe technique de Lueur Externe suit ces évolutions de près et les intègre dans ses projets clients dès qu’elles atteignent une maturité suffisante. C’est cette veille constante depuis plus de 20 ans qui permet de proposer des solutions toujours à la pointe.

Mise en place concrète : par où commencer

Si vous n’avez jamais écrit de tests sur votre projet, voici un plan d’action progressif :

1. Installez Vitest (ou Jest) et écrivez votre premier test sur une fonction utilitaire simple.
2. Ajoutez Testing Library et testez votre composant le plus critique (formulaire de contact, panier e-commerce, authentification).
3. Configurez la couverture de code pour identifier les zones non testées.
4. Intégrez les tests à votre pipeline CI/CD (GitHub Actions, GitLab CI, etc.).
5. Fixez un objectif de couverture progressif : 50 % le premier mois, 70 % à trois mois, 80 % à six mois.

Cette approche incrémentale évite le syndrome du “on teste tout d’un coup” qui épuise les équipes et produit des tests de mauvaise qualité.

Conclusion : investir dans les tests, c’est investir dans la sérénité

Tester son code JavaScript n’est plus un luxe réservé aux grandes entreprises tech. Avec des outils comme Jest, Vitest et Testing Library, la barrière d’entrée n’a jamais été aussi basse. La syntaxe est accessible, la documentation est excellente et les bénéfices sont immédiats : moins de bugs, des déploiements plus confiants et un code plus facile à faire évoluer.

Le choix entre Jest et Vitest dépend de votre stack technique. Quant à Testing Library, elle devrait faire partie de la boîte à outils de tout développeur front-end en 2025.

Vous souhaitez mettre en place une stratégie de test robuste sur votre projet web ou e-commerce ? Les experts de Lueur Externe accompagnent les entreprises depuis 2003 dans la conception et le développement d’applications web fiables et performantes. Que ce soit pour un audit de code, la mise en place de tests automatisés ou le développement complet de votre projet, nous sommes là pour vous aider.

Contactez-nous pour échanger sur vos besoins et donner à votre projet la fiabilité qu’il mérite.