Vai al contenuto principale

Jest 14.0: Test degli Snapshot dell’Albero React

· 6 min di lettura
Christoph Nakazawa
Christoph Nakazawa
Traduzione Beta Non Ufficiale

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

Uno dei principi di Jest è offrire un'esperienza integrata "a configurazione zero". Vogliamo rendere il più semplice possibile scrivere test validi e utili. Abbiamo osservato che quando gli ingegneri hanno a disposizione strumenti pronti all'uso, finiscono per scrivere più test, il che si traduce in codebase stabili e sane.

Una delle grandi domande aperte era come scrivere test React in modo efficiente. Esistono molti strumenti come ReactTestUtils e enzyme. Entrambi sono ottimi e vengono utilizzati attivamente. Tuttavia, gli ingegneri ci hanno spesso detto di passare più tempo a scrivere un test che il componente stesso. Di conseguenza, molti hanno smesso completamente di scrivere test, portando infine a instabilità. Gli ingegneri ci hanno detto che volevano semplicemente assicurarsi che i loro componenti non cambiassero inaspettatamente.

In collaborazione con il team React, abbiamo creato un nuovo renderer di test per React e aggiunto gli snapshot test a Jest. Considera questo test di esempio per un semplice componente Link:

import renderer from 'react-test-renderer';
test('Link renders correctly', () => {
  const tree = renderer
    .create(<Link page="http://www.facebook.com">Facebook</Link>)
    .toJSON();
  expect(tree).toMatchSnapshot();
});

La prima volta che questo test viene eseguito, Jest crea un file snapshot simile a questo:

exports[`Link renders correctly 1`] = `
<a
  className="normal"
  href="http://www.facebook.com"
  onMouseEnter={[Function bound _onMouseEnter]}
  onMouseLeave={[Function bound _onMouseLeave]}>
  Facebook
</a>
`;

L'artefatto dello snapshot deve essere commitato insieme alle modifiche al codice. Utilizziamo pretty-format per rendere gli snapshot leggibili durante la code review. Nelle esecuzioni successive, Jest confronterà semplicemente l'output renderizzato con lo snapshot precedente. Se coincidono, il test passerà. Se non coincidono, o l'implementazione è cambiata e lo snapshot deve essere aggiornato con jest -u, o il test runner ha trovato un bug nel tuo codice che dovrebbe essere corretto.

Se modifichiamo l'indirizzo a cui punta il componente Link nel nostro esempio, Jest mostrerà questo output:

test-con-snapshot

Ora sai che devi accettare le modifiche con jest -u, o correggere il componente se le modifiche erano involontarie. Per provare questa funzionalità, clona l'esempio snapshot, modifica il componente Link ed esegui Jest. Abbiamo aggiornato il Tutorial React con una nuova guida per il test degli snapshot.

Questa funzionalità è stata sviluppata da Ben Alpert e Cristian Carlesso.

Supporto sperimentale per React Native​

Creando un renderer di test non legato a piattaforme specifiche, siamo finalmente in grado di supportare una versione completa e non simulata di React Native. Siamo entusiasti di lanciare il supporto sperimentale per React Native in Jest tramite il pacchetto jest-react-native.

Puoi iniziare a usare Jest con react-native eseguendo yarn add --dev jest-react-native e aggiungendo il preset alla tua configurazione Jest:

"jest": {
  "preset": "jest-react-native"
}
info

Il preset attualmente implementa solo il set minimo di configurazione necessario per iniziare con i test di React Native. Speriamo in contributi della comunità per migliorare questo progetto. Provatelo e segnalate issue o inviate pull request!

Perché il test degli snapshot?​

Per le app native di Facebook utilizziamo un sistema chiamato "snapshot testing": un sistema di test che renderizza i componenti UI, acquisisce uno screenshot e successivamente confronta lo screenshot registrato con le modifiche apportate da un ingegnere. Se gli screenshot non coincidono, ci sono due possibilità: o il cambiamento è inaspettato, oppure lo screenshot può essere aggiornato alla nuova versione del componente UI.

Mentre questa era la soluzione che volevamo per il web, abbiamo anche riscontrato molti problemi con i test end-to-end che i test di snapshot integrati risolvono:

  • Nessuna instabilità: Poiché i test vengono eseguiti in un runner da riga di comando invece che in un browser reale o su un telefono, il test runner non deve attendere build, avviare browser, caricare pagine o guidare l'interfaccia utente per portare un componente nello stato desiderato. Queste operazioni tendono a essere instabili e producono risultati rumorosi.

  • Velocità di iterazione: Gli sviluppatori vogliono risultati in meno di un secondo anziché attendere minuti o addirittura ore. Se i test non sono rapidi come nella maggior parte dei framework end-to-end, gli sviluppatori non li eseguono affatto o evitano di scriverli.

  • Debug: È più semplice analizzare il codice di un test di integrazione in JavaScript piuttosto che ricreare lo scenario di un test screenshot e capire cosa sia successo nel diff visivo.

Poiché crediamo che il testing degli snapshot possa essere utile oltre Jest, abbiamo separato la funzionalità nel pacchetto jest-snapshot. Siamo felici di collaborare con la comunità per renderlo più generico e integrarlo con altri test runner, condividendo concetti e infrastrutture.

Ecco infine la testimonianza di uno sviluppatore Facebook su come il testing degli snapshot ha trasformato la sua esperienza:

“Una delle sfide maggiori nel mio progetto era mantenere sincronizzati i file di input e output per ogni caso di test. Ogni piccola modifica funzionale poteva alterare tutti i file di output. Con il testing degli snapshot non ho più bisogno dei file di output: Jest genera gratuitamente gli snapshot! Posso semplicemente verificare come Jest aggiorna gli snapshot anziché apportare manualmente le modifiche.” – Kyle Davis lavorando a fjs.

Prossime tappe per Jest​

Recentemente Aaron Abramov si è unito full time al team Jest per migliorare la nostra infrastruttura di test unitari e di integrazione per i prodotti ads di Facebook. Nei prossimi mesi il team pianifica importanti miglioramenti:

  • Sostituire Jasmine: Jasmine ci rallenta e non è più attivamente sviluppato. Stiamo sostituendo tutti i matcher di Jasmine per aggiungere nuove funzionalità ed eliminare questa dipendenza.

  • Code Coverage: Quando Jest è stato creato, strumenti come Babel non esistevano. Il supporto al code coverage presenta edge case e non funziona sempre correttamente. Lo stiamo riscrivendo per risolvere tutti i problemi attuali.

  • Esperienza sviluppatore: Miglioreremo il processo di setup, il debugging, la CLI e la documentazione.

  • Mocking: Il sistema di mocking, specialmente per i mock manuali, è confuso e problematico. Vogliamo renderlo più rigoroso e comprensibile.

  • Performance: Stiamo lavorando su ulteriori ottimizzazioni per codebase molto grandi.

Come sempre, se hai domande o vuoi contribuire, contattaci!