Test di unità JavaScript: Guida completa 2026

Probabilmente ti trovi in una delle due situazioni attualmente. O il tuo progetto JavaScript ha quasi nessun test e ogni rifattura sembra rischiosa, o già hai test e la metà di loro sono lente, fragili e difficili da fidarsi.

Che peggiora in Capacitor e applicazioni Electron. Una semplice funzionalità può toccare logica commerciale condivisa, API del browser, plugin nativi, file locali, IPC e servizi remoti nello stesso flusso. Se testi quelle parti in modo sbagliato, il tuo set di test diventa un labirinto di dipendenze fake. Se le testi nel modo giusto, ottieni feedback veloci sulla logica che si rompe. Buoni test di unità JavaScript non iniziano con sintassi di matcher astuta. Iniziano con un confine disciplinato: testa la logica pura direttamente, isolare gli effetti collaterali e evita di scrivere test che si sbriciolano non appena rinomini una funzione interna.

Elenco dei Contenuti

Scegliere il tuo framework di testing JavaScript

• Perché un framework non è facoltativo
  • Perché un framework non è facoltativo
  • Jest vs Mocha in una sola occhiata
  • Ciò che consiglio per la maggior parte delle squadre
• Configurazione del progetto e il tuo primo test
  • Una configurazione Jest semplice
  • Scrivi il test prima del code
  • Utilizza Arrange Act Assert ogni volta
• Migliorare le Mock e le Code asincrone
  • Definisci i confini dei mock, non tutto
  • Un modello migliore per Capacitor e Electron code
  • Testare flussi asincroni senza instabilità
• Strategie avanzate per test robusti
  • Utilizza lo split di testing come budget
  • La copertura è una torcia, non un obiettivo
  • I test comportamentali sopravvivono ai refactoring
• Test per CI, Capacitor, e App Electron
  • Configura CI come percorso di esecuzione predefinito
  • Testare le interazioni del plugin Capacitor
  • Testare il main renderer e l'IPC code di Electron
• Domande Frequenti Sulle Unit Test di JavaScript
  • Cosa differenzia le unit test, le integrazioni e le E2E
  • Dovremmo mirare a una copertura completa
  • Come aggiungere test a un codice esistente

Scegliere il tuo framework di testing JavaScript

Un progetto JavaScript professionale ha bisogno di un vero e proprio esecutore di test. I script ad hoc e le verifiche manuali del console non scalano quando più ingegneri toccano lo stesso codice. Hai bisogno di scoprire i test, delle affermazioni, del trattamento degli async, dei mock e di una via per eseguire tutto in modo coerente nel development locale e CI.

La guida attuale converge sempre di più su un piccolo insieme di opzioni mainstream. Jest, Mocha e Jasmine sono ripetutamente evidenziati come i principali framework, con Jest che spesso viene messo in evidenza per la struttura di test integrata, le affermazioni, il mocking e il supporto async in un unico pacchetto, come mostrato in questo lab di testing JavaScript di Pluralsight Un diagramma di confronto che mostra i popolari framework di testing JavaScript, inclusi Jest, Mocha, Cypress e Playwright..

Il primo errore che le squadre commettono è trattare i test unitari come un'attività secondaria. Ciò porta spesso a nomi di file inconsistenti, affermazioni personalizzate che nessuno ricorda e aiuti che solo una persona comprende.

Un framework ti dà un linguaggio condiviso:

Struttura di test

• con __CAPGO_KEEP_0__ describe e test o it
• Assert con matcher di lettura
• Hook per la configurazione e la pulizia
• Supporto Async per promesse e timer
• Strumenti di simulazione per dipendenze esterne

Se il tuo team ha anche bisogno di una visione più ampia dell'automazione dei test al di là del lavoro a livello di unità, Capgo offre una panoramica utile di test automatizzati nei flussi di consegna di applicazioni.

Jest vs Mocha in sintesi

Jest e Mocha rappresentano due filosofie diverse.

Jest è l'opzione tutto-in-uno. Consegna la maggior parte di ciò che le squadre hanno bisogno già dal primo giorno.
Mocha è più modulare. Consegna un esecutore e si aspetta che tu assembli il resto della pila.

Regola pratica: Se il tuo team deve chiedere quale libreria di asserzione e quale libreria di mocking utilizzare con il runner, probabilmente vuoi Jest.

Ciò che consiglio per la maggior parte dei team

Per la maggior parte dei progetti moderni, sceglierei Jest a meno che il codice non abbia già forti motivi per rimanere su Mocha. Questa raccomandazione diventa più forte quando l'applicazione include Capacitor o Electronperché questi progetti hanno già abbastanza parti in movimento. Ridurre la dispersione dei strumenti di testing si ripaga velocemente.

Rimane senso utilizzare Mocha nei servizi Node.js più vecchi o nelle codebase a lungo termine dove l'ecosistema circostante è già stabilito. Ma per un ingegnere di livello medio che sta configurando un robusto set di test da zero, Jest rimuove di solito più frizione di quella che crea.

Nota importante di campo. Cypress e Playwright sono eccellenti strumenti, ma risolvono un problema diverso. Sono meglio adatti per i controlli a livello di browser e a fine-test, non per il rapido ciclo interno dove i test di unità dovrebbero vivere.

Configurazione del Progetto e Primo Test

Un setup di testing pulito dovrebbe essere noioso. Se l'aggiunta del primo test sembra complicata, il set di test probabilmente non rimarrà sano.

Una configurazione Jest semplice

Inizia con un progetto JavaScript che già ha un package.jsonPoi aggiungi Jest come dipendenza di sviluppo e collega uno script di test.

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

Basta così per molti progetti. Puoi aggiungere più configurazioni in seguito se il tuo sistema di moduli, la transpilazione o la struttura di monorepo richiedono.

Se stai costruendo un'app Capacitor localmente e vuoi che il tuo ambiente di sviluppo sia in ordine prima di aggiungere i test intorno alla logica condivisa, il Capgo's guida per impostare un ambiente Capacitor locale E' un compagno di viaggio pratico.

Scrivi il test prima del code

Il modello test-first non è solo una preferenza personale. La guida JavaScript della Consumer Financial Protection Bureau degli Stati Uniti raccomanda esplicitamente di scrivere il test prima, organizzare i test con describe e it, e formulare controlli intorno expect(...) asserzioni nella sua guida di testing unitario JavaScript.

Questo conta perché il test-first cambia come si progetta code. Le funzioni tendono a diventare più piccole, le dipendenze diventano più visibili e gli effetti collaterali smettono di infiltrarsi nella logica che dovrebbe rimanere pura.

Ecco un esempio minimale:

// 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);
  });
});

Usa Arrange Act Assert ogni volta

Il Il pattern Arrange, Act, Assert mantiene i testi leggibili, anche quando diventano più complessi. Il pattern di testo mantiene i testi leggibili, anche quando diventano più complessi.

1. Preparare Prepara l'input e qualsiasi setup necessario.
2. Agisci Chiamare la funzione.
3. Assicurati Verifica l'esito.

Applicato a un helper di validazione:

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);
  });
});

I test piccoli invecchiano bene. Un test dovrebbe di solito rispondere a una sola domanda, non narrare un intero workflow.

Per i progetti Capacitor e Electron, quella disciplina conta di più perché la tua logica pura spesso si trova accanto all'integrazione nativa o desktop code. Mantieni la regola commerciale testabile senza il runtime della piattaforma, e il tuo primo test non sarà l'ultimo utile.

Masterizzare i Mock e l'asincrono Code

La maggior parte dei bug nell'applicazione code non proviene dall'aggiunta di due numeri. Proviene da code che raggiunge al di fuori di sé: richieste di rete, file, plugin API, timer, canali IPC, layer di archiviazione.

Quello è dove aiuta il mocking. Gli dà il controllo sul confine affinché il test possa concentrarsi sulla decisione di code

Mockare i confini, non tutto

La guida per le prove mantenibili enfatizza la copertura del comportamento singolo e una sola affermazione forte per il test, e anche avverte che l'uso eccessivo dei mock rende le prove fragili e strettamente legate ai dettagli di implementazione, come riassunto in questo articolo di TestRail sui test unitari mantenibili.

Quel avvertimento conta molto in JavaScript. Gli squadre spesso iniziano facendo mockare ogni modulo importato e finiscono per testare se le funzioni chiamano altre funzioni nell'ordine 'corretto', invece di testare il comportamento reale.

Obiettivo sbagliato per un test pesante di mock:

• se l'aiutante A ha chiamato l'aiutante B
• se il servizio C ha chiamato il serializzatore D
• se una funzione interna privata è stata eseguita due volte

Obiettivo migliore:

• cosa il funzionale ha restituito
• se ha gestito una dipendenza fallita correttamente
• se ha trasformato i dati nella forma attesa

A better pattern for Capacitor and Electron code

In applicazioni mobili e desktop, preferisco un layer di avvolgimento intorno alle API native o di piattaforma. Poi i test unitari simulano il wrapper, non la piattaforma stessa.

Esempio di struttura:

// 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 });
});

Quel modello funziona anche per Electron. Avvolgi ipcRendereraccesso ai file, o integrazioni shell, dietro un adattatore sottile.

Per i team che testano la logica di rilascio e le vie di aggiornamento negli app Capacitor, Capgo ha una guida rilevante su testare gli aggiornamenti OTA Capacitor con scenari di mock.

Un breve walkthrough può essere utile se il tuo team sta ancora normalizzando lo stile di test asincrono:

Testare flussi asincroni senza instabilità

Usa async/await in test quando l'code in test ritorna una promessa. È più chiaro rispetto ai pattern pesanti di callback e più facile da debuggare.

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');
});

Anche testa la via del fallimento:

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');
});

Testa sia la via felice che la via brutta. In produzione, la via brutta è quella che gli utenti ricordano.

Strategie Avanzate per Test Robusti

Un insieme di test diventa utile quando rimane utile anche dopo che l'code è cambiato. È più difficile di quanto non sia scrivere un mucchio di test che passano.

Usa lo split di testing come un budget

Una guida pratica raccomanda una 70/20/10 split su test di unità, integrazione e test end-to-end, con i test di unità che forniscono il feedback più veloce e le fallite più stabili. Lo stesso consiglio dice che un completo insieme di test di unità dovrebbe finire in meno di 10 secondi, e le verifiche pre-commit dovrebbero rimanere meno di 5 secondi, secondo questo guida di testing OpenReplay.

Considero questo come uno strumento di budgeting, non una religione. Se la maggior parte del tuo sforzo va ai test end-to-end, il tuo team attendrà troppo a lungo per ricevere feedback. Se tutto è unitario, perderai i reali confini del sistema.

Per un'applicazione Capacitor o Electron, un equilibrio sano solitamente assomiglia a questo:

• Unit tests per test logica di prezzo, regole di accesso, serializzazione, eleggibilità di aggiornamento, flag di feature e trasformazioni di stato Integration tests per adattatori di archiviazione, wrapper di plugin e contratti di IPC
• E2E tests per alcuni viaggi critici come login, flusso di acquisto, sincronizzazione o promemoria di aggiornamento La copertura è una torcia, non un obiettivo
• Il rapporto di copertura è utile quando aiuta a individuare rami non testati in logica importante. Diventa dannoso quando gli squadre inseguiamo percentuali di copertura per il loro proprio interesse. Un validatore di accesso con test di edge-case pensati fornisce più valore di un file coperto pieno di affermazioni triviali. È specialmente vero per input pesanti __CAPGO_KEEP_0__ come form, parser, logica di data e controlli di accesso. Se il suo team sta stringendo la qualità intorno alla validazione pesante UI, questo guide su

masterizzare la validazione di form frontend

è un buon complemento alla strategia di testing a livello di unità.

A login validator with thoughtful edge-case tests gives more value than a covered file full of trivial assertions. That’s especially true for input-heavy code such as forms, parsers, date logic, and permission checks. If your team is tightening quality around validation-heavy UI, this guide on Unit tests for pricing logic, permissions rules, serialization, update eligibility, feature flags, and state transforms

Integration tests for storage adapters, plugin wrappers, and IPC contracts

A suite affidabile dovrebbe consentirti di rifare gli interni senza ri scrivere metà dei test. La via più facile per arrivare là è affermare comportamento osservabile al posto di dettagli di implementazione.

Usi del caso che mantengono bene:

• Condizioni di confine come input vuoto, valori nulli, tipi non validi, e stringhe sovrastanti
• Esiti del dominio come “ritornano negati per mancanza di autorizzazione”
• Transizioni di stato come “marca aggiornamento come pendente dopo download metadata è stato validato”

Usi del caso che spesso marciano:

• esaminare chiamate di aiuto interno
• verifica la sequenza di metodi privati
• mocka ogni layer nella catena di chiamata

Per gli squadre di app che stanno costruendo processi di rilascio disciplinati, l'articolo di Capgo su assicurazione della qualità dell'app è utile perché collega il lavoro di testing al pipeline di rilascio più ampio.

Testing per CI, Capacitor, e App di Electron

Un test che si esegue solo su una macchina del singolo sviluppatore non è un sistema di sicurezza. È un'abitudine locale.

CI trasforma i test unitari del lavoro JavaScript in infrastruttura di squadra. Ogni push, richiesta di pull o branch di rilascio può esercitare le stesse comandi con le stesse aspettative. Quella consistenza è ancora più importante per i progetti Capacitor e Electron, dove il drift dell'ambiente causa fallimenti sottili.

Fate di CI la via di esecuzione predefinita

Almeno, il vostro CI dovrebbe installare le dipendenze e eseguire il set di unit test su ogni set di modifiche. Tenere identico il comando alle possibilità di sviluppo locale quando possibile.

Un flusso di lavoro di GitHub Actions base può essere così piccolo:

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

Quello è sufficiente per catturare importazioni rotte, affermazioni fallite e assunzioni di piattaforma accidentali prima che arrivino in main.

For le squadre mobili che distribuiscono attraverso pipeline automatizzate, Capgo ha una guida pratica per impostare CI/CD per le app Capacitor.

Testare le interazioni del plugin Capacitor

La maniera sbagliata per testare le unità del plugin Capacitor code è di estrarre i plugin nativi direttamente in ogni servizio. Questo lega il tuo set di test alla bridge del platform.

La migliore strategia è una sottile astrazione:

// 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 stessa idea si applica all'accesso alla fotocamera, alle richieste biometriche, alla registrazione dei token di push e allo stato della rete. Mantieni le chiamate dei plugin nelle adapter. Testa la logica dell'app contro gli interfacce che controlli.

Testare code IPC per l'app Electron

Gli app Electron hanno due importanti giunture: processo principale code e processo renderer codeNon confonderle nei test.

A una configurazione affidabile si affiancano spesso:

• Test delle unità del renderer per i modelli di visualizzazione, lo stato, la formattazione e la logica di business per l'interfaccia utente
• Test delle unità del processo principale per i menu, le operazioni sui file e le decisioni sul ciclo di vita dell'applicazione
• Test del contratto IPC per la forma dei messaggi e le risposte previste

Esempio di 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' });
});

Se in seguito cambierai l'implementazione interna da un helper all'altro, questo test rimane valido perché verifica il comportamento che conta. È questo lo standard che desideri per desktop e mobile code.

Domande frequenti sul testing delle unità JavaScript

Cosa differenzia i test di unità, integrazione e E2E

A test unitario controlla una piccola porzione di logica in isolamento. Un test di integrazione controlla se alcuni componenti o servizi funzionano correttamente insieme. Un test end-to-end esercita un percorso di utilizzo attraverso l'applicazione in esecuzione.

Usa i test unitari per una conferma veloce delle regole commerciali. Usa i test di integrazione per le giunzioni come archiviazione, wrapper dei plugin e IPC. Usa i test E2E con parsimonia per i flussi di lavoro che si sarebbero seriamente danneggiati se si fossero rotti.

Dovremmo mirare a una copertura completa

No. Una copertura completa può spingere i team verso test di basso valore.

La copertura è utile quando rivela rischi code che nessuno ha esercitato. Non è utile quando gli ingegneri aggiungono affermazioni superficiali solo per soddisfare un dashboard. Se il suo set di test è fragile, una copertura maggiore non lo salverà.

Come aggiungere test a un codice esistente

Inizia dove le modifiche già avvengono. Non fermare il team e annunciare una grande riscrittura della strategia di test.

A una sequenza pratica assomiglia questo:

• Protetti attivi code prima aggiungendo test a moduli che toccate durante il lavoro di feature o bug fixes
• Estrae logica pura da file difficili da testare in modo che le regole di affari possano essere testate senza rumore del framework o runtime
• Aggiungi rivestimenti di fessura intorno a plugin nativi, client di rete, chiamate al filesystem e IPC di Electron
• Rifiuta modelli fragili quando si introducono mock. La guida da le migliori pratiche di testing del JavaScript è specialmente utile qui perché evidenzia il problema spesso trascurato dell'over-mocking e i test fragili che ne seguono

Lo scopo non è la completezza immediata. È un miglioramento costante nei luoghi in cui le regressioni costano più al team.

Se il tuo team rilascia Capacitor o applicazioni Electron e ha bisogno di un processo di rilascio più pulito per le modifiche al JavaScript, Capgo è una delle opzioni da considerare. Offre aggiornamenti in tempo reale per le applicazioni CapacitorJS e Electron, con controlli di rollout e visibilità, quindi i team possono associare test di unità solide a un percorso più sicuro per il rilascio delle modifiche al bundle web senza dover attendere la revisione della store per ogni correzione.