Come testare la libreria React Native: guida completa

La tua suite di test React Native è verde, ma un utente riferisce che premendo ‘Continua’ non succede nulla su un dispositivo reale. Il test del componente ha trovato il pulsante, ha chiamato il suo gestore e ha visto la schermata attesa in un ambiente JavaScript simulato. Non ha mai verificato la richiesta di autorizzazione nativa, il comportamento della tastiera, l'animazione, la piattaforma API o la navigazione reale.

Quel divario è dove le squadre ottengono una falsa fiducia. Libreria di Test per React Native E' eccellente per testare cosa un componente rende e come risponde all'interazione dell'utente, ma non è una sostituzione per il testing dei dispositivi o la misurazione delle prestazioni. La strategia affidabile è utilizzare ogni layer per i fallimenti che può esporre.

Indice dei Contenuti

• Perché il Testing Centrato sull'Utente Cambia Tutto
  • Test the behavior users depend on
  • Sai cosa non dimostrano i test che passano
• Installazione e Configurazione che Funziona Effettivamente
  • Conserva i file di configurazione espliciti
• API Core Query e Assert Explained
  • Scegli la query in base al tempo e all'intento
  • Preferisci le dichiarazioni specifiche rispetto alle snapshot
• Modelli pratici per i componenti, gli hook e la navigazione
  • Componenti presentazionali
  • Navigazione e dati asincroni
  • Mock dei moduli nativi
• Debugging dei test instabili, controlli di CI e prestazioni
  • Rendere le fallite di CI riproducibili
  • Considera le prestazioni come misura, non come affermazione
• Mettere tutto a punto e procedere
  • Un percorso di migrazione pratico

Perché il testing centrato sull'utente cambia tutto

A un testo comune fallisce prima ancora che il testo sia scritto. Un sviluppatore esamina le proprietà di un componente, accede allo stato del componente o confronta un grande snapshot perché quei dettagli sono facili da affermare. Il test passa, poi un refactor cambia la struttura del componente senza cambiare l'esperienza, e il set di test fallisce. In peggio, il test può continuare a passare mentre il comportamento visibile per l'utente è sbagliato perché l'affermazione non descriveva mai cosa l'utente doveva vedere.

La React Native Testing Library prende un approccio opposto. Si rende il componente, si interagisce con esso attraverso un controllo visibile, quindi si afferma l'esito che un utente può osservare. Quell'approccio corrisponde all'esempio user-centric della React Native Testing Librarye alla guida di testing di React Native per mantenere i testi brevi, concentrare ogni test su una cosa sola, separare le preoccupazioni di visualizzazione dalle logiche di business e dallo stato, e preferire l'output visibile o gli aiuti di accessibilità rispetto ai dettagli di implementazione interna.

Test the behavior users depend on

Supponga un form di accesso che disabilita il suo bottone di invio mentre si esegue una richiesta. Un test fragile potrebbe controllare disabled su un particolare istanza di componente o affermare che una variabile di stato è cambiata. Un test più forte preme il controllo accessibile "Accedi", attende l'indicatore di caricamento e controlla che un messaggio di errore o la schermata di destinazione apparisca.

Il secondo test non si preoccupa di sapere se il form utilizza uno stato locale, un riduttore, un hook personalizzato o una diversa implementazione del pulsante. Si preoccupa che l'app comunichi il risultato giusto.

Regola pratica: Se un utente non può osservarlo, chiediti se appartiene a un test del comportamento di un componente.

Le query basate sui nomi e sui ruoli degli elementi di accessibilità forzano una migliore produttività del prodotto code. Una schermata che esponga etichette significative è più facile da utilizzare con tecnologie assistive e più facile da esercitare in test. Quella connessione conta quando si valuta l'esperienza dell'utente più ampia. esperienza dell'utente dell'app, perché la testabilità e l'usabilità migliorano spesso insieme.

Sappiate cosa non dimostrano i test che passano

Un test di componente centrato sull'utente può dimostrare che JavaScript rende la branca attesa e risponde a un presso simulato. Non può dimostrare che un prompt biometrico si apre correttamente, che una fotocamera nativa restituisce un risultato utilizzabile o che un flusso di pagamento sopravvive al comportamento di ciclo di vita specifico della piattaforma.

Quella frontiera non è una debolezza della libreria. È una ragione per mantenere onesti i livelli di test. Utilizzate RNTL per il comportamento dei componenti, quindi riservate i test basati su dispositivi per i flussi in cui l'integrazione nativa, la navigazione reale, le autorizzazioni, l'autenticazione, i pagamenti o la funzionalità di base dell'app possono cambiare il risultato.

Installazione e Configurazione che Funziona Effettivamente

La configurazione moderna inizia con il pacchetto scoping:

@testing-library/react-native

Il più vecchio react-native-testing-library npm il nome del pacchetto esiste ancora come artefatto storico, ma i progetti attuali dovrebbero utilizzare il pacchetto con nome di dominio mantenuto all'interno della famiglia di Testing Library. Il progetto’s GitHub repository lo descrive come utilità React Native per incoraggiare buone pratiche di testing, e la sua storia di rilascio mostra che la libreria ha continuato a cambiare insieme a React Native piuttosto che rimanere un aiuto statico.

Installa la libreria con il tuo ambiente Jest esistente. I progetti Expo utilizzano comunemente il preset Jest di Expo, mentre i progetti React Native nudi utilizzano la configurazione Jest di React Native:

npm install --save-dev @testing-library/react-native jest

Per Expo, aggiungi il preset che il tuo progetto utilizza già:

{
  "scripts": {
    "test": "jest"
  },
  "jest": {
    "preset": "jest-expo"
  }
}

Per un'applicazione React Native nuda, utilizza la configurazione Jest corrispondente di React Native. Mantieni il preset allineato con la versione del framework. Molti errori che sembrano essere problemi di RNTL derivano da un renderer React, una trasformazione Babel o un preset Jest non allineati.

Tieni i file di configurazione espliciti

Metti la configurazione dell'ambiente condivisa in un file di configurazione piuttosto che ripetere le mock in ogni test:

// jest.setup.js
import '@testing-library/react-native/extend-expect';

Poi riferiscilo da Jest:

{
  "jest": {
    "preset": "jest-expo",
    "setupFilesAfterEnv": ["<rootDir>/jest.setup.js"]
  }
}

Se il tuo app utilizza React Navigation, Reanimated, gestione di gesti, contesto di area sicura o moduli di archiviazione, configura solo le mock che il tuo ambiente di test necessita. Una mock globale che cambia il comportamento dell'applicazione può rendere ogni test più facile da superare, ma rende il suite meno affidabile.

TypeScript ha bisogno di attenzione analoga. Assicurati che Jest trasformi .ts e (E) .tsx i file vengono trasmessi attraverso la configurazione predefinita o la tua configurazione Babel, e mantengono disponibili i tipi di test per il compilatore. Un test che esegue localmente ma non viene controllato dal tipo può nascondere nomi di query errati, parametri di navigazione non validi o forme di mock non sicure.

La cronologia delle versioni è utile per diagnosticare consigli di configurazione più vecchi. Le liste del progetto 127 rilasci, con v14.0.1 etichettato il 23 giugno 2026, mentre v12.9.0, rilasciato il 27 novembre 2024, aggiunto supporto ufficiale per React Native 0.77 e Expo 52. La linea alpha di v14 nel marzo 2025 è passata al Renderer di test universale da React Test Renderer obsoleto e si è preparata per il supporto React 19 solo. Questi dettagli sono disponibili nella cronologia dei rilasci RNTL, quindi non copiare una dipendenza di renderer da un tutorial obsoleto senza verificare le versioni del tuo app.

Per una fondazione Jest pratica, confronta la tua configurazione con questo guida di testing unitario JestEsegui quindi un test di un piccolo componente prima di aggiungere la navigazione e i mock nativi.

API di base Query e Asserzioni Spiegate

I test RNTL diventano affidabili quando le loro query corrispondono a ciò che un utente può vedere, trovare e operare. Il API è piccolo, ma scegliere un selettore che esponga dettagli di implementazione può rendere un test di passaggio ingannevole.

Inizia con render:

const screen = render(<LoginForm />);

Scegli la query più rilevante per l'utente disponibile. Preferisci le query orientate all'accessibilità quando il componente le espone, utilizza il testo visibile quando il testo è il comportamento e riserva testID per casi senza un selettore utente significativo o dove è necessario un hook di integrazione stabile.

Scegli la query in base al tempo e all'intento

Ogni famiglia di query ha un scopo distinto:

• Presenza sincrona: Usa getByRole, getByText, o un altro getBy La query si esegue quando l'elemento dovrebbe già esistere. Il test fallisce immediatamente se non lo trova.
• Apparenza asincrona: Usa findByRole o findByText Quando l'apparizione o l'interazione causa un aggiornamento asincrono.
• Controlli di assenza: Usa queryByText o queryByTestId Quando un elemento può essere mancante e si aspetta un risultato nullo invece di un'eccezione.
• Selettori di fallback: Usa getByTestId intenzionalmente. Dà una robusta presa alle complesse controlli, ma non dovrebbe sostituire le etichette accessibili in tutto l'applicazione.

For le prove di eventi focalizzati, fireEvent.press è diretto:

fireEvent.press(screen.getByRole('button', { name: 'Save' }));

Usa userEvent quando la versione installata supporta la sequenza di interazione più realistica. In ogni caso, assicurati che il risultato dell'interfaccia utente sia:

expect(await screen.findByText('Saved')).toBeTruthy();

Una dichiarazione di asserzione per un handler si adatta a un componente il cui contratto pubblico è una callback di evento. È debole come unica prova che il percorso dell'utente funziona.

Preferere affermazioni specifiche rispetto alle snapshot

Affermazioni valide descrivono lo schermo:

expect(screen.getByText('Account created')).toBeTruthy();
expect(screen.getByRole('button', { name: 'Continue' })).toBeEnabled();

Possono anche verificare lo stato di accessibilità, la selezione e la feedback di validazione visibile. Evita di controllare la connessione interna:

expect(screen.getByTestId('submit-button').props.onPress).toBeDefined();

Quella dichiarazione dimostra che una proprietà esiste, non che il feature funziona. Le snapshot di piccole dimensioni, intenzionali, possono catturare i cambiamenti strutturali, mentre le grandi snapshot di navigazione o schermata spesso creano recensioni rumorose e rendono facili le approvazioni non spiegate.

Il pacchetto di Testing Library appartiene alla più ampia testing-library npm organizzazione. I suoi pacchetti attivi includono @testing-library/react-nativecon la versione 13.3.3 pubblicato nel 2026secondo le informazioni del repository informazioni del repositoryConvenzioni di query condivise aiutano a livello di piattaforma, ma non decidono quale asserzione rappresenta il comportamento del tuo prodotto.

Per una comparazione più ampia delle pratiche di testing dei componenti Jest, vedi questo guida a il testing unitario di React. RNTL si ferma ancora alla frontiera del componente JavaScript. Le autorizzazioni native, le pile di navigazione reali, i tasti del dispositivo, il timing della finestra e il comportamento della memoria richiedono strumenti E2E o di prestazioni piuttosto che più mock dei componenti.

Il video qui sotto mostra il workflow di query e asserzione nel contesto.

Modelli pratici per i componenti, gli hook e la navigazione

Un test suite utile segue la forma dell'applicazione. I componenti presentazionali richiedono test di comportamento diretti, gli hook richiedono input e output controllati, la navigazione richiede un provider realistico abbastanza, e i moduli nativi richiedono mock che rimangano chiaramente diversi dalla verifica del dispositivo reale.

Componenti presentazionali

Conserva un test di componente vicino al suo contratto pubblico:

const onSelect = jest.fn();

render(
  <PlanCard
    title="Team"
    description="Shared workspace"
    onSelect={onSelect}
  />
);

fireEvent.press(screen.getByRole('button', { name: 'Choose Team' }));

expect(onSelect).toHaveBeenCalled();

La label esatta dovrebbe corrispondere alla tua interfaccia utente. La parte importante è che il test trovi il controllo in modo che un utente o un servizio di accessibilità lo faccia e confermi l'output visibile o di callback che conta. Non mockare ogni componente figlio per impostazione predefinita. Mocka solo i confini costosi o non correlati quando essi oscurano il comportamento da testare.

Per un hook personalizzato, utilizza renderHook quando la versione di RNTL installata lo fornisce:

const { result } = renderHook(() => useSearch());

await act(async () => {
  await result.current.submit('query');
});

expect(result.current.status).toBe('success');

Il test del hook dovrebbe controllare il confine di rete o di repository, non riprodurre l'intera app. Testa la schermata separatamente per sapere se lo stato del hook diventa utile per l'interfaccia utente.

La navigazione e i dati asincroni

For navigation behavior, rendering a screen inside a real NavigationContainer and a small test navigator is often more valuable than mocking every navigation method. Press a visible control, wait for the destination content, and assert the new screen’s output. A direct useNavigation mock is still appropriate for a small button whose only responsibility is dispatching a typed route, but it won’t validate route registration, parameters, or nested navigator behavior.

Async data deserves the same discipline. Mock the API or repository response, render the screen, assert the loading state, resolve the request, then assert success or error output. Use findBy Verifica le query per gli elementi previsti e rendi espliciti i richieste negate, altrimenti un test può passare perché il componente non ha raggiunto la branca prevista.

Moduli nativi simulati

Le simulazioni per AsyncStorage, autorizzazioni, fotocamere, biometrie e API di piattaforma sono utili per test JavaScript deterministici. Non sono una prova che il feature nativo funziona. Mantieni il comportamento di mock vicino al contratto del modulo, resetta le chiamate tra i test e include le risposte di fallimento al posto di modellare solo la via felice.

Il confine è pratico: mocka la dipendenza per testare le tue decisioni JavaScript, quindi esegui un test di dispositivo per confermare il comportamento reale della dipendenza.

Debugging Test di Fluttuazione CI e Verifiche di Prestazioni

Un test fluttuante spesso indica un tempo non controllato, uno stato condiviso o un'asserzione che gareggia con l'interfaccia utente. Identifica la condizione presente prima di aumentare i tempi di timeout. Un timeout più lungo può nascondere il problema di programmazione e rendere il set di test più lento.

Usa findBy per gli elementi previsti per apparire dopo un aggiornamento. Usa waitFor per le condizioni di stato o le chiamate mock. Se i timer fittizi sono abilitati, avanzali al punto in cui l'interazione richiede e ripristina i timer reali in seguito. Un act avverte che React ha osservato un aggiornamento fuori dal suo limite di interazione previsto. Correggi il mancante awaitinterazione dell'utente o timer di pulizia invece di sopprimere l'avviso.

Rendere le fallite di CI riproducibili

Un lavoro CI affidabile installa dal file di lock, esegue lo stesso comando Jest utilizzato localmente e isolizza lo stato mock. Cancella le chiamate mock tra i test, resetta i moduli quando lo stato modulo-a-modulo influisce sul comportamento e elimina le dipendenze dall'ordine di esecuzione. La cache Jest accelera la feedback, ma le modifiche di dipendenza o configurazione richiedono una invalidazione della cache appropriata.

Le fallite di CI esclusivamente richiedono una comparazione dell'ambiente prima di una riscrittura del componente. Controlla Node, il gestore di pacchetti, le impostazioni del lavoratore Jest, la configurazione dei timer e le variabili di ambiente. Riproduci lo stesso comando localmente dove possibile, quindi riduci il test che fallisce alla minima interazione che esponga la differenza.

L'osservabilità copre un gap diverso. Un tool come Sentry per React Native fornisce contesto di errore di produzione che i test dei componenti mockati non possono riprodurre, compresi gli errori legati a dispositivi reali e integrazioni native.

Security-sensitive journeys need a second boundary. Use component tests for validation and state transitions, then add device-level coverage for the handoff and native behavior. For one-time-code flows, consult guidance on how to verifica flussi di autenticazione SMS quando quella integrazione fa parte del percorso.

Tieni il rendimento come misura, non come affermazione.

Un test funzionale può confermare che una lista si rende. Non può determinare in modo affidabile se un refactor ha cambiato la durata della renderizzazione o il conteggio della renderizzazione, perché il tempo di esecuzione del test aggiunge rumore. Assicura di misurare quei valori per uno scenario, ripeti lo scenario per ridurre la varianza e applica l'analisi statistica prima di segnalare un cambiamento significativo. La sua documentazione di testing del rendimento anche copre la relazione dei dati adatti per la revisione di CI e pull-request.

Evita le affermazioni fisse come “la renderizzazione deve finire sotto un limite scelto.” Un lavoratore di CI impegnato può attivare un fallimento falso, mentre un limite rilassato può non rilevare una regressione reale. Utilizza le misurazioni ripetute per i segnali di regressione, quindi ispeziona il componente e il profilo del dispositivo quando la comparazione mostra una differenza significativa.

Regola di misura: Test funzionali rispondono se il comportamento è corretto. Gli strumenti di prestazioni rispondono se uno scenario misurato è cambiato. Tenere separate queste domande.

Mettilo tutto insieme e procedi avanti

La React Native Testing Library appartiene alla ampia e veloce strato della tua strategia di test. Dovrebbe coprire il comportamento dei componenti, i cambiamenti di stato visibili, gli esiti di accessibilità, la validazione, gli stati dei dati simulati e l'integrazione tra i componenti JavaScript. Mantieni quei test focalizzati su cosa un utente può osservare, e fai in modo che le fallite puntino a un comportamento specifico piuttosto che a un grande albero di rendering.

Il layer basato sul dispositivo più piccolo dovrebbe proteggere i flussi dove i mock possono nascondersi. Panoramica di testing stati che RNTL non fornisce un runtime React Native completo e non può testare le funzionalità native. Lo stesso consiglio raccomanda di associare i test dei componenti con gli strumenti E2E come Detox per i flussi critici, inclusi l'autenticazione, i pagamenti e la funzionalità di base dell'app.

Un percorso di migrazione pratica

Non è necessario riscrivere un insieme esistente in un passo.

1. Conserva i test aziendali preziosi. Sposta la logica di stato pura e di dominio in test unitari focalizzati dove forniscono feedback chiaro.
2. Sostituisci le affermazioni di implementazione per primo. Verifica le proprietà e gli stati interni tramite output visibili, stato di accessibilità e risultati di interazione.
3. Riduci le snapshot. Conserva solo le snapshot che i revisori possono comprendere e mantenere.
4. Aggiungi copertura dei confini nativi. Per ogni modulo importante mockato, identifica il comportamento del dispositivo che ancora richiede una validazione.
5. Proteggi i viaggi critici. Aggiungi copertura E2E per l'autenticazione, il pagamento, la navigazione core, i permessi e altri flussi in cui il comportamento nativo può cambiare il risultato.
6. Misura separatamente le schermate sensibili. Usa confronti di prestazioni ripetuti per liste, feed e percorsi di rendering costosi al posto di supporre da Jest duration.

Per la fiducia di rilascio, collega il set alla integrazione di testing CI/CD e richiedi il livello di test appropriato prima di spedire. Se un fix di JavaScript o di asset deve raggiungere gli utenti dopo la validazione, Capgo può consegnare pacchetti web firmati ai canali mirati per le applicazioni CapacitorJS e Electron, con controlli di rollout e protezione del rollback. Questo workflow di consegna non sostituisce i test dei dispositivi React Native, ma illustra lo stesso principio: valuta il comportamento al livello in cui si esegue.

La domanda giusta non è se React Native Testing Library può testare l'intera app. Non può, e il confine ufficiale è utile. La domanda giusta è se ogni rischio importante ha un test in esecuzione nell'ambiente in grado di esporlo.

Capgo collega le modifiche JavaScript e di asset validate a una consegna controllata per i team di CapacitorJS e Electron, con canali mirati, visibilità di rollout e protezione del rollback. Visita Capgo per vedere come si adatta al tuo componente, E2E e CI testing workflow.