Come testare le app con React Native Testing Library

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

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

Indice dei Contenuti

• Perché il Testing Centrato sull'Utente Cambia Tutto
  • Test the behavior users depend on
  • Conoscere cosa non dimostra la passaggio dei test
• Installazione e configurazione che funziona effettivamente
  • Tenere i file di configurazione espliciti
• API di base, query e affermazioni spiegate
  • Scegliere la query in base al tempo e all'intento
  • Preferire le affermazioni 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 fluttuanti, CI e controlli di prestazioni
  • Rendere riproducibili le fallite del CI
  • Considerare la prestazione come misura, non come affermazione
• Mettere insieme tutto e procedere
  • Un percorso di migrazione pratico

Perché il testing centrato sull'utente cambia tutto

Un comune errore di test inizia prima che il test 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 si rompe. In peggio, il test può continuare a passare mentre il comportamento visibile per l'utente è sbagliato perché l'asserzione non descriveva mai cosa l'utente doveva vedere.

La Libreria di testing React Native 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 Esempio di React Native Testing Library centrato sull'utente, nonché la guida di testing di React Native per mantenere i test brevi, concentrarsi su 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'istanza specifica di un componente o afferma che una variabile di stato è cambiata. Un test più forte preme il controllo di accesso “Accedi”, attende l'indicatore di caricamento e controlla che un messaggio di errore o la schermata di destinazione apparisca.

La seconda prova non si cura di sapere se il form utilizza uno stato locale, un riduttore, un hook personalizzato o una diversa implementazione del pulsante. Si cura di sapere che l'app comunica 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 su etichette di accessibilità e ruoli forzano anche una migliore produttività del prodotto code. Una schermata che esporre 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. l'esperienza dell'utente dell'app, perché la testabilità e l'usabilità migliorano spesso insieme.

Sapere cosa non dimostrano le prove di passaggio

Un test di un componente centrato sull'utente può dimostrare che JavaScript rende la branca attesa e risponde a un presso simulato. Non può dimostrare che un promemoria biometrico si apre correttamente, che una fotocamera nativa restituisce un risultato utile 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 le layer di test oneste. Utilizza RNTL per il comportamento dei componenti, quindi riserva i test basati sul dispositivo per i flussi in cui l'integrazione nativa, la navigazione reale, i permessi, l'autenticazione, i pagamenti o la funzionalità di base dell'app possono cambiare il risultato.

Installazione e Configurazione che Funziona Effettivamente

Impostazione moderna inizia con il pacchetto a scope:

@testing-library/react-native

Il più vecchio react-native-testing-library npm il nome del pacchetto ancora esiste come artefatto storico, ma i progetti attuali dovrebbero utilizzare il pacchetto a livello di ambito mantenuto all'interno della famiglia di Testing Library. Il repository del progetto 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 a nudo possono utilizzare il preset React Native:

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

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

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

Per un'applicazione React Native a nudo, utilizza la configurazione Jest corrispondente di React Native. Mantieni il preset allineato con la versione del framework. Molti errori che sembrano problemi di RNTL derivano da un mismatched React renderer, Babel transform o preset Jest.

Tieni i file di configurazione espliciti

Metti la configurazione dell'ambiente condivisa in un file di configurazione piuttosto che ripetere i 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, il trattamento dei gesti, il contesto dell'area di sicurezza o i moduli di archiviazione, configura solo le mock che il tuo ambiente di test necessita. Una mock globale che modifica il comportamento dell'applicazione può rendere ogni test più facile da superare, ma renderebbe il set di test meno affidabile.

Il TypeScript richiede la stessa attenzione. Assicurati che Jest trasformi .ts e .tsx i file attraverso il preset o la tua configurazione Babel, e mantieni i tipi di test disponibili 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 2026mentre v12.9.0, rilasciato il 27 novembre 2024, aggiunto supporto ufficiale per React Native 0.77 e Expo 52Il v14 alpha line in marzo 2025 è passato al Renderer di Test Universale da React Test Renderer obsoleto e si è preparato per il supporto React 19 solo. Questi dettagli sono visibili nella cronologia dei rilasci RNTLQuindi non copiare una dipendenza di renderer da un tutorial datato senza verificare le versioni del tuo'applicazione.

Per una fondazione Jest pratica, confronta la tua configurazione con questa Guida di testing unitario JestEsegui quindi un piccolo test del 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:

• Sincronia di presenza: Usa getByRole, getByText, o un'altra getBy query quando l'elemento dovrebbe già esistere. Il test fallisce immediatamente se non lo fa.
• Asincronia di apparizione: Usa findByRole o findByText quando la rendering 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 deliberatamente. Dà a controlli complessi un gancio duraturo, ma non dovrebbe sostituire etichette accessibili in tutta l'applicazione.

Per test 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 gestore di eventi si adatta a un componente il cui contratto pubblico è un callback di evento. È debole come unica prova che il percorso dell'utente funziona.

Preferisci dichiarazioni specifiche alle snapshot

Le buone dichiarazioni 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();

Quell'asserzione dimostra l'esistenza di una proprietà, non che il feature funzioni. Le piccole, intenzionali snapshot possono catturare i cambiamenti strutturali, mentre le grandi snapshot di navigazione o schermo spesso creano recensioni rumorose e rendono facili le approvazioni di aggiornamenti non spiegati.

Il pacchetto Testing Library appartiene alla più ampia testing-library npm organizzazione. I suoi pacchetti attivi includono @testing-library/react-native, con versione 13.3.3 pubblicata nel 2026, secondo le informazioni del repository del progetto informazioni del repositoryPer una comparazione più ampia delle pratiche di testing dei componenti Jest, vedi questo guide al

Vedere questo guida per una comparazione più ampia delle pratiche di testing dei componenti con Jest. testistica di unità per React. RNTL still stops at the JavaScript-rendered component boundary. Native permissions, real navigation stacks, device keyboards, frame timing, and memory behavior need E2E or performance tooling rather than more component mocks.

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

Modelli pratici per Componenti, Hook e Navigazione

Un insieme di test utili segue la forma dell'applicazione. I componenti presentazionali richiedono test di comportamento diretto, 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.

I 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 nel modo in cui un utente o un servizio di accessibilità lo farebbe e confermi l'outpout visibile o di callback che conta. Non mockare ogni componente figlio per impostazione predefinita. Mocka solo i confini costosi o non correlati quando 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 dell'hook dovrebbe controllare il confine di rete o di repository, non riprodurre l'intera app. Testa la schermata separatamente per sapere se lo stato dell'hook diventa utile per l'interfaccia utente.

La navigazione e i dati asincroni

Per il comportamento di navigazione, rendere una schermata all'interno di un vero NavigationContainer e un piccolo navigatore di test è spesso più utile che mockare ogni metodo di navigazione. Premi un controllo visibile, aspetta il contenuto di destinazione e assicurati che l'output della nuova schermata sia corretto. Un diretto useNavigation mock è ancora appropriato per un piccolo pulsante la cui unica responsabilità è l'invio di una rotta tipizzata, ma non validizzerà la registrazione della rotta, i parametri o il comportamento del navigatore nidificato.

La data asincrona merita la stessa disciplina. Mocka il API o la risposta del repository, rendi lo schermo, afferma lo stato di caricamento, risolvi la richiesta, quindi afferma l'output di successo o errore. Utilizza findBy le query per gli elementi previsti e rendi esplicite le richieste rifiutate, altrimenti un test può passare perché il componente non ha raggiunto la branca intesa.

Mock dei moduli nativi

Mocks for AsyncStorage, permissions, cameras, biometrics, and platform APIs are useful for deterministic JavaScript tests. They aren’t evidence that the native feature works. Keep mock behavior close to the module contract, reset calls between tests, and include failure responses instead of modeling only the happy path.

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

Debugging Test Fluttuanti CI e Verifiche di Prestazioni

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

Usare findBy per gli elementi previsti di apparire dopo un aggiornamento. Usare 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 ripristinare i timer reali in seguito. Un act avviso significa che React ha osservato un aggiornamento fuori dal confine di interazione previsto. Correggi il mancante awaitinterazione dell'utente o timer di pulizia invece di sopprimere l'avviso.

Rendere le fallite 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 alle dipendenze o alla configurazione richiedono una invalidazione della cache appropriata.

Le fallimenti esclusivamente di CI richiedono una comparazione dell'ambiente prima di una riscrittura del componente. Controlla Node, il gestore dei pacchetti, le impostazioni dei lavoratori Jest, la configurazione del timer e le variabili di ambiente. Riproduci la stessa richiesta localmente dove possibile, quindi riduci il test fallito alla minima interazione che esporre la differenza.

La visibilità copre un diverso gap. Uno strumento come Sentinel 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.

Gli itinerari sensibili alla sicurezza hanno bisogno di un secondo confine. Utilizza i test dei componenti per la validazione e le transizioni di stato, quindi aggiungi una copertura a livello di dispositivo per il passaggio e il comportamento nativo. Per flussi one-time-code, consulta le linee guida su come verifica flussi di autenticazione SMS quando quella integrazione fa parte del percorso.

Tratta la prestazione 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. Rassicura misura quei valori per uno scenario, ripete lo scenario per ridurre la varianza e applica l'analisi statistica prima di riportare un cambiamento significativo. La sua documentazione di testing delle prestazioni anche copre la relazione dei dati adatti per la revisione di CI e pull-request.

Evitare le dichiarazioni fisse come “questa render deve finire sotto un certo limite.” Un lavoratore CI impegnato può attivare un falso fallimento, mentre un limite rilassato può non rilevare una regressione reale. Utilizzare misure ripetute per i segnali di regressione, quindi ispezionare il componente e il profilo 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. Tieni separate queste domande.

Mettere tutto insieme e procedere

La React Native Testing Library appartiene alla larga, veloce layer 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. Tenere questi test focalizzati su cosa un utente può osservare e far fallire puntando 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 dei test Stati che RNTL non fornisce un runtime React Native completo e non può testare le funzionalità native. Lo stesso consiglio raccomanda di associare le prove 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 pratico

Non è necessario riscrivere un insieme esistente in un passo.

1. Conservare le prove utili per l'azienda. Spostare la logica di stato e di dominio in prove di unità focalizzate dove forniscono feedback chiaro.
2. Sostituire le dichiarazioni di implementazione prima. Verifica le proprietà e gli stati interni tramite output visibili, stato di accessibilità e risultati di interazione.
3. Ridurre le snapshot. Conservare solo le snapshot che i revisori possono comprendere e mantenere.
4. Aggiungere copertura dei confini nativi. Per ogni modulo mockato importante, identificare il comportamento del dispositivo che ancora richiede la validazione.
5. Protettori di 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. Misurare separatamente le schermate sensitive. 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, collegare il set alla integrazione di testing CI/CD e richiede la giusta layer di test prima di spedire. Se un fix 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 di dispositivi React Native, ma illustra lo stesso principio: validare il comportamento alla layer dove si esegue.

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

Capgo collega le modifiche JavaScript e asset validate ai canali controllati per le squadre di CapacitorJS e Electron, con visibilità di distribuzione e protezione del rollback. Visita Capgo vedere come può adattarsi al tuo componente, E2E e CI testing workflow.