Vai al contenuto principale

Jest 15.0: Nuove Impostazioni Predefinite per Jest

· 9 min di lettura
Traduzione Beta Non Ufficiale

Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →

Nell'ultimo anno abbiamo reso Jest più veloce, più facile da configurare, abbiamo aggiunto tantissime funzionalità e implementato lo snapshot testing. Tuttavia, abbiamo dedicato poche risorse a due aree: l'output della CLI e l'esperienza utente. Con Jest 15 stiamo rivoluzionando il framework per renderlo più accessibile sia ai principianti che agli utenti esperti. Siamo entusiasti che il nostro investimento in Jest stia dando i suoi frutti: possiamo muoverci rapidamente e migliorare il framework per Facebook e la comunità open source alla velocità della luce. L'obiettivo di Jest è essere completo "out-of-the-box" e richiedere il minimo necessario di configurazione. Recentemente abbiamo avuto modo di spiegare la nostra filosofia in una issue di create-react-app.

La modifica più importante riguarda una serie di nuove impostazioni predefinite. Se sei un utente esistente di Jest, molto probabilmente dovrai aggiornare la tua configurazione per Jest 15. Nella maggior parte dei casi semplificherà la tua configurazione e Jest fornirà messaggi d'errore utili durante l'aggiornamento. Tutte le nuove impostazioni predefinite possono essere disabilitate in base alle tue esigenze, ma riteniamo ancora che le funzionalità disabilitate siano fondamentali per Jest in determinati scenari e continueremo a utilizzarle e supportarle a lungo termine in Facebook. La nostra documentazione API è stata completamente riscritta per riflettere questi cambiamenti. Questa pull request per React evidenzia alcune modifiche necessarie per i progetti esistenti.

Nuovi messaggi e riepiloghi d'errore nella CLI

Nell'ambito dello sforzo per rimuovere gradualmente Jasmine da Jest, la sostituzione di tutti i matcher di Jasmine è quasi completata. Abbiamo dedicato molto tempo a perfezionare ogni messaggio d'errore per ogni matcher, per fornire il miglior feedback possibile quando un test fallisce – il momento in cui Jest dovrebbe darti il massimo valore. Oltre a stampare i valori attesi e ricevuti, viene mostrato un diff per i matcher toBe e toEqual per individuare più facilmente gli errori. Sono stati aggiunti più colori e i file rilevanti negli stack trace sono evidenziati in modo più prominente.

Ecco un confronto tra prima e dopo su un terminale chiaro: failure1 Funziona bene anche con colori scuri: failure2

Nuovo comando watch

Abbiamo completamente riscritto jest --watch per renderlo più interattivo. Ora può alternare tra l'esecuzione di tutti i test o solo dei file di test correlati ai file modificati premendo a o o. Premendo p appare un prompt che permette di specificare un pattern di test per concentrarsi su un insieme specifico di file. Gli snapshot test possono essere aggiornati premendo u.

watch

Miglioramenti a jest-react-native

Sono stati aggiunti mock per ListView, TextInput, ActivityIndicator, ScrollView e altri. I mock esistenti sono stati aggiornati per utilizzare le implementazioni reali e gli snapshot esistenti dovranno probabilmente essere aggiornati passando a Jest 15. È stata aggiunta una funzione mockComponent a jest-react-native che può essere usata per simulare componenti nativi:

jest.mock('MyNativeComponent', () => {
const jestReactNative = require('jest-react-native');
return jestReactNative.mockComponent('MyNativeComponent');
});

Sono stati apportati anche numerosi miglioramenti alla simulazione di immagini, al modulo fetch e ad altre API native.

Messaggi Console Bufferizzati

Jest parallelizza l'esecuzione dei test tra worker per massimizzare le prestazioni. In precedenza, Jest inoltrava immediatamente i messaggi console dai worker al processo principale. Durante l'esecuzione parallela di più test, era spesso difficile capire quale test e quale modulo stesse chiamando una funzione di log. In Jest 15, tutti i messaggi console sono bufferizzati e stampati insieme ai risultati dei singoli test. Inoltre, vengono stampati il file e il numero di riga della chiamata di log per facilitare l'ispezione del codice.

Confronta l'output della versione precedente di Jest e di Jest 15: console

Disattivazione automatica del mocking

Il mocking automatico è ora disabilitato di default in Jest. Questa era di gran lunga la funzionalità più confusa per i nuovi utenti e in molti casi non ha senso per progetti piccoli. Abbiamo introdotto il mocking automatico a Facebook e ha funzionato benissimo quando il testing unitario è stato adottato in una grossa codebase esistente con pochi test, ma col tempo ci siamo accorti che le persone passavano più tempo a combattere con moduli mockati/non mockati di quanto impiegherebbero a scrivere un test normalmente. Abbiamo anche notato che gli autori di librerie spesso richiedono un enorme numero di moduli base che devono sempre essere smockati manualmente. Persino per Jest stesso abbiamo realizzato che la maggior parte dei test aveva il mocking automatico disabilitato manualmente. Continuiamo a credere che il mocking automatico esplicito possa essere incredibilmente utile. Questo cambiamento semplicemente sostituisce mock impliciti con mock espliciti tramite chiamate a jest.mock(moduleName).

Se desideri ancora usare il mocking automatico di default, abilita l'opzione automock nella tua configurazione o chiama manualmente jest.enableAutomock() nel tuo file di test o di setup.

Modelli di file di test

Non tutti usano la stessa convenzione della cartella __tests__ per memorizzare i test. Jest 15 cerca anche file che terminano con .spec.js o .test.js, due standard popolari nella community. Jest 15 rimuove inoltre le opzioni di configurazione testDirectoryName e testFileExtensions e chiede agli utenti di passare all'opzione testRegex quando vengono usate le vecchie opzioni di configurazione.

Persistenza del registro dei moduli

Jest reimpostava implicitamente tutti i moduli prima di ogni test e consigliavamo di richiedere moduli in beforeEach o all'interno dei test. Questo è utile quando i moduli hanno stato locale che non dovrebbe essere condiviso tra i test. Tuttavia, sono avvenuti due grandi cambiamenti: i moduli ES con la sintassi import di primo livello e un rinnovato interesse nello scrivere moduli funzionali senza stato.

Ciò ha portato a numerose incompatibilità. Abbiamo anche notato che in Facebook non stavamo nemmeno usando questo reset implicito. Invece facevamo affidamento su chiamate esplicite a jest.resetModules(), che mette gli ingegneri in controllo su quando cancellare tutto lo stato.

Ecco un esempio:

const React1 = require('react');
jest.resetModules();
const React2 = require('react');

React1 !== React2; // These two are separate copies of React.

La chiamata a resetModules cancella la cache dei require. Una seconda chiamata per richiedere lo stesso modulo risulterà in una nuova istanziazione dello stesso modulo e di tutte le sue dipendenze. Questa funzionalità è particolarmente utile quando si ha a che fare con moduli che hanno effetti collaterali, come jest-haste-map.

Crediamo sia meglio dare il controllo agli utenti, quindi abbiamo disabilitato il reset implicito. I moduli possono essere reimpostati usando jest.resetModules() nel codice e l'opzione resetModules può essere abilitata nella configurazione per ripristinare il comportamento precedente.

Timer reali vs fittizi

Di default Jest mockava tutte le funzioni timer come setTimeout o process.nextTick e forniva un'API jest.runAllTimers() per far avanzare i timer programmaticamente. Questo è utile quando un frammento di codice imposta un timeout lungo che non vogliamo attendere in un test.

Tuttavia abbiamo scoperto che la maggior parte delle volte i casi d'uso sono piuttosto isolati. Anche la programmazione asincrona è diventata molto più semplice nel nostro test runner. Jest ora usa i timer reali di default.

Puoi ancora sovrascrivere questo comportamento specificando "timers": "fake" nella configurazione o chiamando gli switch globali jest.useRealTimers() e jest.useFakeTimers().

setupEnvScriptFile vs setupFiles

L'opzione di configurazione setupEnvScriptFile è stata deprecata da tempo. Jest 15 la rimuove completamente e la sostituisce con setupFiles. Questa opzione si aspetta un array di percorsi di file che vengono caricati in ordine prima che un file di test venga eseguito.

Supporto riscritto per la code coverage

La copertura del codice in Jest è disponibile tramite jest --coverage e non richiede pacchetti aggiuntivi o configurazione. Il supporto alla code coverage è stato completamente riscritto ed è stata aggiunta l'opzione collectCoverageFrom per raccogliere informazioni sulla copertura da interi progetti, inclusi file non testati. Nota che questa opzione utilizza glob poiché miriamo a semplificare ulteriormente le opzioni di configurazione future fornendo un'alternativa più semplice alle espressioni regolari. Vedi il package.json di Jest per un esempio.

Altri Miglioramenti

Sono stati apportati anche numerosi altri miglioramenti:

  • Migliorate le prestazioni per esecuzioni di test piccoli.

  • Jest ora utilizza la modalità verbose quando viene eseguito un solo file di test.

  • Aggiunta l'opzione --env per sovrascrivere l'ambiente di test configurato.

  • moduleNameMapper ora utilizza un algoritmo di risoluzione.

  • Jest ora funziona con percorsi contenenti caratteri speciali, come le parentesi.

  • Aggiunto global.global all'ambiente node.

  • Risolto l'errore non valido di babel-plugin-jest-hoist quando una funzione utente casuale veniva chiamata mock.

  • Correzione della risoluzione di testEnvironment per preferire jest-environment-{name} invece del solo {name}. Questo previene collisioni di moduli quando si utilizza jsdom come ambiente di test.

  • Miglioramenti all'infrastruttura di test di Jest unendo test di integrazione e unità. Ora viene raccolta la code coverage per Jest stesso.

Siamo soddisfatti nel guardare indietro a tutti i cambiamenti realizzati con l'aiuto della comunità e non potremmo essere più entusiasti di rendere Jest ancora migliore nei prossimi mesi. Per favore segnala un problema se qualcosa non funziona come previsto e inviaci pull request.

Prossimo passo: Concurrent Reporter.