Tests Unitaires JavaScript : Guide Complet 2026

bun

May 29, 2026 Capacitor et applications Electron. Une fonctionnalité simple peut toucher la logique commerciale partagée, les API du navigateur, les plugins natifs, les fichiers locaux, les IPC et les services distants dans le même flux. Si vous testez ces pièces de la mauvaise façon, votre ensemble de tests devient un labyrinthe de dépendances fictives. Si vous les testez de la bonne façon, vous obtenez un feedback rapide sur la logique qui ne fonctionne pas. Les bonnes tests unitaires ne commencent pas par une syntaxe de matcheur astucieux. Cela commence par une frontière disciplinée : tester la logique pure directement, isoler les effets secondaires et éviter d'écrire des tests qui s'effondrent dès que vous renommez une fonction interne.

Table des matières

Choisir votre cadre de test JavaScript

Pourquoi un cadre n'est pas optionnel
Une mise en place simple de Jest
Maîtriser les mocks et les Code asynchrones
Stratégies avancées pour des tests robustes
Tester pour CI, Capacitor, et les applications Electron
Foire aux questions sur les tests unitaires de JavaScript

Choisissez votre cadre de test de JavaScript

Un projet de JavaScript professionnel nécessite un vrai exécuteur de tests. Les scripts ad hoc et les vérifications manuelles de la console ne s'adaptent pas une fois que plusieurs ingénieurs touchent le même codebase. Vous avez besoin de la découverte des tests, des assertions, de la gestion des appels asynchrones, des mocks et une façon de lancer tout de manière cohérente en développement local et CI.

La guidance actuelle converge vers une petite gamme d'options principales. Jest, Mocha et Jasmine sont régulièrement mis en avant comme les principaux cadres, avec Jest Jest, Mocha et Jasmine sont régulièrement mis en avant comme les principaux cadres, avec Jest souvent mis en avant pour sa structure de test intégrée, ses assertions, sa simulation et son support async dans un seul package, comme le montre ceci Laboratoire de test JavaScript de Pluralsight.

Un tableau de comparaison montrant les frameworks de test JavaScript populaires, y compris Jest, Mocha, Cypress et Playwright.

Pourquoi un framework n'est pas optionnel

La première erreur que les équipes commettent est de considérer les tests unitaires comme une activité secondaire. Cela conduit généralement à des noms de fichiers incohérents, des assertions personnalisées que personne ne se rappelle, et des aides que seul un seul personne comprend.

Un framework vous donne un langage partagé :

Structure de test avec describe et test ou it
Assertions avec des matcheurs lisibles
Hooks pour la configuration et la désconfiguration
Support Async pour les promesses et les temporisations
Outils de simulation pour les dépendances externes

Si votre équipe a également besoin d'une vue d'ensemble plus large de la test automation au-delà du travail au niveau unitaire, Capgo présente un aperçu utile de la mise en œuvre automatique de tests dans les flux de livraison d'applications.

Jest vs Mocha en un coup d'œil

Jest et Mocha représentent deux philosophies différentes.

Jest est l'option tout-en-un. Il embarque la plupart de ce dont les équipes ont besoin dès le premier jour.
Mocha est plus modulaire. Il vous donne un exécuteur et vous attend pour assembler le reste de la pile.

Fonctionnalité	Jest	Mocha
Complexité de configuration	Moins pour la plupart des équipes	Plus élevé car vous ajoutez généralement des bibliothèques d'assertion et de simulation
Assertions	Intégré	Généralement associé à une autre bibliothèque
Simulation	Intégré par défaut	Généralement associé à une autre bibliothèque
Test en mode asynchrone	Intégré par défaut et direct	Supporté, mais dépend plus de la configuration entourante
Flux de couverture	Intégré couramment dans le même flux de travail	Souvent plus assemblé pièce par pièce
Meilleure correspondance	Nouveaux projets, équipes qui veulent de la cohérence	Étapes de legacy, équipes qui veulent un contrôle modulaire

Règle pratique: Si votre équipe doit demander quel bibliothèque d'assertion et quelle bibliothèque de simulation doivent être associées au lanceur, vous avez probablement envie de Jest.

Pour la plupart des projets modernes, je choisirais Jest sauf si le codebase a déjà de solides raisons de rester sur Mocha. Cette recommandation devient encore plus forte lorsque l'application inclut Capacitor ou Electron, car ces projets ont déjà suffisamment de parties en mouvement. La réduction de la dispersion des outils de test rapporte rapidement.

Mocha est toujours pertinent dans les services Node.js plus anciens ou les codebases longéviques où l'écosystème autour de lui est déjà stabilisé. Mais pour un ingénieur de niveau moyen qui configure une suite robuste à partir de zéro, Jest élimine généralement plus de friction qu'il ne la crée.

Une importante note de portée. Cypress et Playwright sont de très bons outils, mais ils résolvent un problème différent. Ils sont mieux adaptés aux vérifications de niveau navigateur et aux tests finaux, et non à la boucle rapide interne où les tests unitaires doivent vivre.

Configuration du projet et votre premier test

Un environnement de test propre devrait être ennuyeux. Si l'ajout de la première test ressent compliqué, le suite probablement ne restera pas en bonne santé.

Un homme portant des lunettes travaillant sur un projet de programmation sur un ordinateur portable sur un bureau en bois.

Un setup Jest simple

Commencez avec un projet JavaScript qui a déjà un package.json. Ajoutez ensuite Jest en tant que dépendance de développement et reliez un script de test.

{
  "scripts": {
    "test": "jest"
  }
}

Cela suffit pour beaucoup de projets. Vous pouvez ajouter plus de configuration plus tard si votre système de module, votre transpilation ou votre structure de monorepo le nécessitent.

Si vous construisez une application Capacitor localement et que vous voulez que votre environnement de développement soit en ordre avant d'ajouter des tests autour de la logique partagée, le guide de Capgo sur la mise en place d'un environnement local Capacitor est un compagnon pratique.

Écrivez le test avant le code

Le modèle test-first n'est pas juste une préférence personnelle. La recommandation de la protection financière du Bureau des États-Unis recommande explicitement d'écrire le test en premierorganiser les tests avec describe et it, et encadrer les vérifications autour expect(...) des affirmations dans ses guidance de test unitaire JavaScript.

Cela compte car les changements test-first modifient la façon dont vous concevez code.

Les fonctions tendent à devenir plus petites, les dépendances deviennent plus visibles et les effets secondaires cessent de se faufiler dans la logique qui devrait rester pure.

// math.js
function addTax(amount, rate) {
  return amount + amount * rate;
}

module.exports = { addTax };

// math.test.js
const { addTax } = require('./math');

describe('addTax', () => {
  it('returns the amount with the tax applied', () => {
    expect(addTax(100, 0.2)).toBe(120);
  });
});

Voici un exemple minimal :

Utilisez Arrange Act Assert chaque fois Le mode Arrange, Act, Assert

garde les tests lisibles, même lorsqu'ils deviennent plus complexes. the input and any needed setup.
Acte en appelant la fonction.
Asserter sur le résultat.

Appliqué à un assistant de validation :

function isSupportedPlatform(platform) {
  return ['ios', 'android', 'web', 'desktop'].includes(platform);
}

describe('isSupportedPlatform', () => {
  it('returns true for ios', () => {
    // Arrange
    const platform = 'ios';

    // Act
    const result = isSupportedPlatform(platform);

    // Assert
    expect(result).toBe(true);
  });
});

Les petites tests vieillissent bien. Un test devrait répondre généralement à une question, et non raconter un flux de travail entier.

Pour les projets Capacitor et Electron, cette discipline compte plus car votre logique pure se trouve souvent à côté d'une intégration native ou de bureau code. Gardez la règle commerciale testable sans le runtime de la plateforme, et votre premier test ne sera pas votre dernier test utile.

Maîtriser les Mocks et les Code Asynchrones

La plupart des bugs dans les applications code ne proviennent pas de l'addition de deux nombres. Ils proviennent de code qui se dépassent : les requêtes réseau, les fichiers, les API des plugins, les timers, les canaux de communication IPC, les couches de stockage.

C'est là où les Mocks sont utiles. Ils vous donnent le contrôle sur la frontière afin que le test puisse se concentrer sur les prises de décision de votre code.

Un diagramme de tableau blanc illustrant une architecture de microservices avec des APIs, des magasins de données, des services externes et un flux de données basé sur les événements.

N'impliquez pas tout

La guidance de test maintenable met l'accent sur la couverture de comportement unique et une affirmation forte par test, et elle avertit également que l'utilisation excessive de mocks rend les tests fragiles et étroitement couplés aux détails d'implémentation, comme le résume cet article de TestRail sur les tests unitaires maintenables.

Cette avertissement compte beaucoup en JavaScript. Les équipes commencent souvent en mockant tous les modules importés et finissent par tester si les fonctions appellent d'autres fonctions dans l'ordre « correct », au lieu de tester le comportement réel.

Cible mauvaise pour un test lourd en mocks :

si l'aide A a appelé l'aide B
si le service C a appelé le sérialiseur D
si une fonction privée interne a été exécutée deux fois

Une cible améliorée :

ce que la fonction a retourné
si elle a géré correctement une dépendance échouée
si elle a transformé les données dans la forme attendue

Un modèle amélioré pour Capacitor et Electron code

Dans les applications mobiles et de bureau, j'ai préféré une couche de wrapper autour des API natives ou de plateforme. Ensuite, les tests unitaires simulent la couche de wrapper, pas la plateforme elle-même.

Structure d'exemple :

// cameraGateway.js
async function getPhoto(cameraPlugin) {
  return cameraPlugin.getPhoto();
}

module.exports = { getPhoto };

// profilePhotoService.js
async function loadProfilePhoto(cameraGateway) {
  const photo = await cameraGateway.getPhoto();
  return { path: photo.path, ready: true };
}

module.exports = { loadProfilePhoto };

// profilePhotoService.test.js
const { loadProfilePhoto } = require('./profilePhotoService');

test('returns mapped photo data', async () => {
  const fakeCameraGateway = {
    getPhoto: jest.fn().mockResolvedValue({ path: '/tmp/pic.jpg' })
  };

  const result = await loadProfilePhoto(fakeCameraGateway);

  expect(result).toEqual({ path: '/tmp/pic.jpg', ready: true });
});

Ce modèle fonctionne également pour Electron. Enveloppez ipcRenderer, l'accès au fichier ou les intégrations de shell derrière un adaptateur mince. Les tests unitaires frappent la couche de service, pas la runtime directement.

Pour les équipes testant la logique de mise à jour et les chemins d'actualisation dans les applications Capacitor, Capgo a une guide pertinent sur la mise à l'épreuve des mises à jour OTA Capacitor avec des scénarios de simulation.

Un aperçu rapide est utile si votre équipe normalise encore le style de test asynchrone :

Testez les flux asynchrones sans instabilité

Utilisez async/await dans les tests lorsque l'code testé renvoie une promesse. C'est plus clair que les modèles lourds en callback et plus facile à déboguer.

async function fetchProfile(api) {
  const response = await api.getUser();
  return response.name;
}

test('returns the user name from the API response', async () => {
  const api = {
    getUser: jest.fn().mockResolvedValue({ name: 'Ava' })
  };

  const result = await fetchProfile(api);

  expect(result).toBe('Ava');
});

Testez également la voie de l'échec :

test('throws when the API request fails', async () => {
  const api = {
    getUser: jest.fn().mockRejectedValue(new Error('network failed'))
  };

  await expect(fetchProfile(api)).rejects.toThrow('network failed');
});

Testez à la fois la voie heureuse et la voie laide. En production, la voie laide est généralement celle que les utilisateurs se rappellent.

Stratégies avancées pour des tests robustes

Un ensemble de tests devient utile lorsqu'il reste utile après les modifications de l'code. C'est plus difficile que d'écrire un tas de tests qui passent.

Un diagramme illustrant des stratégies pour construire un logiciel robuste grâce à une couverture de tests exhaustive et à des ensembles de tests maintenables.

Utilisez le test en deux parties comme un budget

Un guide pratique recommande un 70/20/10 dans les tests unitaires, d'intégration et de fin d'utilisation dans les tests unitaires, d'intégration et de fin d'utilisation, avec des tests unitaires fournissant le feedback le plus rapide et les échecs les plus stables. La même guidance dit qu'un ensemble de tests unitaires complet devrait idéalement se terminer enmoins de 10 secondes , et les vérifications pré-commit devraient restermoins de 5 secondes , selon ce guide de test OpenReplay.

Je considère cela comme un outil de planification, pas une religion. Si la plupart de vos efforts sont consacrés aux tests fin-à-fin, votre équipe attendra trop longtemps pour obtenir des feedback. Si tout est uniquement des tests unitaires, vous manquerez de vraies limites du système.

Pour une application Capacitor ou Electron, un équilibre sain ressemble généralement à ceci :

Tests unitaires pour la logique de tarification, les règles de permissions, la sérialisation, l'éligibilité à la mise à jour, les drapeaux de fonctionnalité et les transformations d'état
Tests d'intégration pour les adaptateurs de stockage, les enveloppes de plugin et les contrats de communication inter-processus
E2E tests pour quelques voyages critiques comme la connexion, le flux d'achat, la synchronisation ou les invitations de mise à jour

La couverture est une lampe, pas un objectif

Les rapports de couverture sont utiles lorsqu'ils vous aident à repérer des branches non testées dans des logiques importantes. Ils deviennent nuisibles lorsque les équipes poursuivent les pourcentages de couverture pour leur propre compte.

Un validateur de connexion avec des tests d'extrémités réfléchis donne plus de valeur qu'un fichier couvert rempli d'assertions triviales. C'est tout particulièrement vrai pour les code chargés en entrées comme les formulaires, les parseurs, la logique des dates et les vérifications des permissions. Si votre équipe resserre la qualité autour de la validation lourde de l'interface utilisateur, ce guide sur la maîtrise de la validation de formulaire frontend est un bon complément à la stratégie de test au niveau unitaire.

Les tests de comportement survivent aux réfacteurs

Un ensemble fiable devrait vous permettre de réfaire les internes sans réécrire la moitié des tests. La meilleure façon de s'y prendre est d'assurer le comportement observable au lieu de détails d'implémentation.

Les cas d'utilisation qui résistent bien :

Conditions de limites comme des entrées vides, des valeurs semblables à null, des types invalides et des chaînes de caractères trop longues
Résultats du domaine comme “les retours sont refusés en raison d'une permission manquante”
Transitions d'état comme “marque l'actualisation comme en attente après la validation des métadonnées de téléchargement”

Utilisations qui se détériorent souvent :

l'inspection d'appels d'aide interne
l'affirmation de la séquence de méthodes privées
le mocking de chaque couche dans la chaîne d'appel

Pour les équipes de développement d'applications qui mettent en place des processus de mise en production disciplinés, l'article de Capgo sur la garantie de la qualité des applications is utile car elle relie le travail de test à la pipeline de publication plus large.

Test pour CI, Capacitor, et les applications Electron

Un test qui ne s'exécute que sur une machine de développeur n'est pas un filet de sécurité. C'est une habitude locale.

CI transforme les tests unitaires en infrastructure d'équipe pour le travail JavaScript. Chaque push, demande de tirage ou branch de version peut exécuter les mêmes commandes avec les mêmes attentes. Cette cohérence compte encore plus pour les projets Capacitor et Electron, où les dérives d'environnement entraînent des échecs subtils.

Fixez CI comme le chemin d'exécution par défaut

Au minimum, votre CI doit installer les dépendances et exécuter le jeu de tests unitaires pour chaque ensemble de modifications. Gardez la commande identique à celle de développement local lorsque possible.

Un workflow d'Actions GitHub basique peut être aussi petit que cela:

name: test

on: [push, pull_request]

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Cela suffit pour capturer les imports brisés, les assertions échouées et les hypothèses de plateforme accidentelles avant qu'elles ne soient intégrées dans la version principale.

Pour les équipes mobiles qui acheminent leurs produits par des pipelines automatisés, Capgo a une guide pratique pour la mise en place de CI/CD pour les applications Capacitor.

Test des interactions du plugin Capacitor

La mauvaise façon de tester les Capacitor code est de tirer les plugins natives directement dans chaque service. Cela couplera votre jeu de tests à la passerelle de plateforme.

Le modèle plus performant est une abstraction fine :

// deviceStorage.js
async function saveFile(filesystem, path, data) {
  return filesystem.writeFile({ path, data });
}

module.exports = { saveFile };

// draftService.js
async function persistDraft(storage, draft) {
  await storage.save('draft.json', JSON.stringify(draft));
  return { saved: true };
}

module.exports = { persistDraft };

// draftService.test.js
const { persistDraft } = require('./draftService');

test('persists a serialized draft', async () => {
  const storage = {
    save: jest.fn().mockResolvedValue(undefined)
  };

  const result = await persistDraft(storage, { title: 'Hello' });

  expect(result).toEqual({ saved: true });
});

La même idée s'applique à l'accès à la caméra, aux invitations biométriques, à l'enregistrement de jetons de poussée et à l'état du réseau. Conservez les appels de plugins dans les adaptateurs. Testez la logique de l'application contre des interfaces que vous contrôlez.

Testez Electron main renderer et IPC code

Les applications Electron ont deux joints importants : processus principal code et processus de rendu code . N'effacez pas ces joints dans les tests.

Un setup fiable sépare généralement :

Tests unitaires de rendu pour les modèles de vue, l'état, la mise en forme et la logique commerciale côté UI
Tests unitaires du processus principal pour les menus, les opérations de fichiers et les décisions de cycle d'application
tests du contrat de communication inter-processus pour la forme des messages et les réponses attendues

Exemple de wrapper IPC :

// ipcGateway.js
function sendSettings(ipcRenderer, payload) {
  ipcRenderer.send('settings:update', payload);
}

module.exports = { sendSettings };

// ipcGateway.test.js
const { sendSettings } = require('./ipcGateway');

test('sends settings update over ipc', () => {
  const ipcRenderer = { send: jest.fn() };

  sendSettings(ipcRenderer, { theme: 'dark' });

  expect(ipcRenderer.send).toHaveBeenCalledWith('settings:update', { theme: 'dark' });
});

Si vous modifiez ultérieurement l'implémentation interne d'un helper à un autre, ce test reste valable car il vérifie le comportement qui compte. C'est le standard que vous souhaitez sur les postes de bureau et les appareils mobiles code.

Questions Fréquentes sur les Tests Unitaires de JavaScript

Quelle est la différence entre les tests unitaires, d'intégration et E2E

A test unitaire vérifie une petite pièce de logique en isolation. Un test d'intégration vérifie si quelques composants ou services fonctionnent ensemble correctement. Un test de bout en bout Les exercices suivent un parcours utilisateur à travers l'application en cours d'exécution.

Utilisez les tests unitaires pour une confiance rapide dans les règles commerciales. Utilisez les tests d'intégration pour les joints tels que le stockage, les enveloppes de plugins et les IPC. Utilisez les tests E2E avec parcimonie pour les workflows qui seraient gravement endommagés s'ils se rompaient.

Faut-il viser une couverture complète

Non. Une couverture complète peut pousser les équipes vers des tests de faible valeur.

La couverture est utile lorsqu'elle révèle des risques code inconnus qui n'ont jamais été exercés. C'est pas utile lorsqu'ingénieurs ajoutent des assertions superficielles juste pour satisfaire un tableau de bord. Si votre ensemble est fragile, une couverture plus élevée ne le sauvera pas.

Comment ajouter des tests à un codebase existant

Commencez là où les changements ont déjà lieu. N'immobilisez pas l'équipe et annoncez une grande refonte de la stratégie de test.

Une séquence pratique ressemble à ceci :

Protégez les code actifs en premier en ajoutant des tests aux modules que vous touchez pendant le travail de fonctionnalité ou les corrections de bogues
Extrayez la logique pure à partir de fichiers difficiles à tester afin que les règles commerciales puissent être testées sans bruitage du cadre ou de l'exécution
Ajoutez des enveloppes de jointure autour de plugins natifs, de clients de réseau, d'appels au système de fichiers et de IPC Electron
Refusez les modèles fragiles lors de l'introduction de faux. Les conseils de la meilleure pratique de test de JavaScript sont particulièrement utiles ici car ils mettent en évidence le problème souvent manqué de sur-mockage et les tests fragiles qui suivent L'objectif n'est pas la complétude immédiate. C'est une amélioration progressive dans les endroits où les régressions coûtent le plus à l'équipe

Si votre équipe expédie

__CAPGO_KEEP_0__ Capacitor Electron Guidance from les applications et nécessite un processus de mise à jour plus propre autour des changements JavaScript, Capgo est une option à considérer. Il fournit des mises à jour en temps réel pour les applications CapacitorJS et Electron, avec des contrôles de déploiement et des capacités d'observation, afin que les équipes puissent associer des tests unitaires solides à un chemin plus sûr vers la livraison des changements de paquet web sans attendre la revue de la boutique pour chaque correction.

Capgo