Come testare la libreria React Native

La tua suite di test React Native è verde, ma un utente riferisce che il pulsante 'Continua' non fa nulla su un dispositivo reale. Il test del componente ha trovato il bottone, chiamato il suo gestore e vide la schermata prevista 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.

Quella lacuna è dove le squadre ottengono una falsa fiducia. React Native Testing Library è 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.

Tavola dei Contenuti

• Perché il Testing Utente Centrico Cambia Tutto
  • Testa il comportamento su cui gli utenti dipendono
  • Sapere cosa non dimostrano i test che passano
• Installazione e Configurazione che Funziona Effettivamente
  • Tenere i file di configurazione espliciti
• API, Query e Affermazioni di Base Spiegate
  • Scegliere la query in base al tempo e all'intento
  • Preferire le affermazioni specifiche rispetto alle snapshot
• Modelli Pratici per Componenti, Hook e Navigazione
  • Componenti presentazionali
  • Navigazione e dati asincroni
  • Mock dei moduli nativi
• Debug dei test instabili, controlli di prestazioni e CI
  • Rendere i fallimenti CI riproducibili
  • Considerare la prestazione come una misura, non come un'asserzione
• Mettere tutto a punto e procedere
  • Un percorso di migrazione pratico

Perché il testing centrato sull'utente cambia tutto

Un comune fallimento 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 l'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 di Libreria di testing React Native centrato sull'utente, insieme alle linee guida di React Native per la gestione dei test, per mantenere i test brevi, concentrarsi su un aspetto alla volta, separare le preoccupazioni relative alla visualizzazione da quelle relative alla logica d'azienda e allo stato, e preferire l'output visibile o gli aiuti di accessibilità rispetto ai dettagli di implementazione interna.

Testare il comportamento su cui gli utenti si affidano.

Supponiamo di avere un modulo di login che disabilita il suo pulsante di invio mentre si esegue una richiesta. Un test fragile potrebbe controllare disabled su una particolare istanza di componente o affermare che una variabile di stato sia cambiata. Un test più forte preme sul controllo accessibile “Accedi”, attende l'indicatore di caricamento e controlla che apparisca un messaggio di errore o la schermata di destinazione.

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

Regola pratica: Se un utente non può osservarlo, si deve dubitare se appartenga a un comportamento di test di componente.

Queries based on accessibility labels and roles also force better product code. A screen that exposes meaningful labels is easier to use with assistive technology and easier to exercise in tests. That connection matters when you assess the broader perché la testabilità e l'usabilità migliorano spesso insieme.Sapere cosa non dimostrano i test che passano.

__CAPGO_KEEP_0__

A un test di componente centrato sull'utente, è possibile dimostrare che JavaScript visualizza la branca attesa e risponde a un presso simulato. Non può dimostrare che una richiesta di autenticazione biometrica si apre correttamente, che una fotocamera nativa restituisce un risultato utilizzabile o che un flusso di pagamento sopravvive al comportamento del 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 l'esito.

Installazione e Configurazione che Funziona Effettivamente

La configurazione moderna inizia con il pacchetto a livello di ambito:

@testing-library/react-native

La versione più vecchia react-native-testing-library npm il nome del pacchetto esiste ancora come artefatto storico, ma i progetti attuali dovrebbero utilizzare il pacchetto a livello di ambito mantenuto all'interno della famiglia della Libreria di Test. Il repository del progetto GitHub lo descrive come strumenti 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 utilizza già:

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

Per un'applicazione React Native di base, utilizzare la configurazione corrispondente di Jest per React Native. Mantenere il preset allineato con la versione del framework. Molti errori che sembrano essere problemi di RNTL derivano da una configurazione non allineata del renderer React, dalla trasformazione Babel o dal preset Jest.

Tenere i file di configurazione espliciti

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

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

Poi fare riferimento a esso da Jest:

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

Se la tua app utilizza React Navigation, Reanimated, gestione di gesti, contesto di area sicura o moduli di archiviazione, configurare 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 rendere il suite meno affidabile.

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 non corretti, parametri di navigazione non validi o forme di mock non sicure.

La cronologia delle rilasci è utile quando si diagnosticano consigli di configurazione più vecchi. Il progetto elenca 127 rilasci, con v14.0.1 etichettato il 23 giugno 2026mentre v12.9.0, rilasciato il 27 novembre 2024, ha aggiunto il supporto ufficiale per React Native 0.77 e Expo 52. La linea alpha v14 di marzo 2025 è passata al Renderer di Test Universale da React Test Renderer obsoleta e si è preparata per il supporto React 19 solo questi dettagli sono riportati nellacronologia di rilascio di 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 questoguida di testing unit Jest

Un infographic che mostra il percorso di installazione a cinque passaggi per impostare il progetto di React Native Testing Library

RNTL tests become trustworthy when their queries match what a user can see, find, and operate. The API is small, but choosing a selector that exposes implementation details can make a passing test misleading.

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

const screen = render(<LoginForm />);

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

Ogni famiglia di query ha un scopo distinto:

Presenza sincrona:

• Utilizza o un'altra getByRole, getByTextquery quando l'elemento dovrebbe già esistere. Il testo fallisce immediatamente se non esiste. getBy Apparizione asincrona:
• Utilizza o findByRole quando l'elemento deve apparire in futuro. Il testo fallisce se non esiste ancora. findByText When si causa un aggiornamento asincrono durante la rendering o l'interazione.
• Controlli di assenza: Usa queryByText o queryByTestId Quando si rende necessario un aggiornamento asincrono durante la rendering o l'interazione.
• Selezionatori di fallback: Usa getByTestId Quando si rende necessario un aggiornamento asincrono durante la rendering o l'interazione.

Usa deliberatamente. Dà a controlli complessi un hook duraturo, ma non sostituire le etichette accessibili in tutto l'applicazione. fireEvent.press Per test di evento focalizzati:

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

è diretto: userEvent Usa quando la versione installata supporta la sequenza di interazione più realistica. In ogni caso, assicurati che il risultato UI sia coerente con le aspettative.

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

A un'asserzione di gestore corrisponde a un componente il cui contratto pubblico è una callback di evento. È debole come unica prova che il percorso dell'utente funziona.

Preferire le asserzioni specifiche rispetto alle snapshot

Le buone asserzioni descrivono la schermata:

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. Evitare di controllare la connessione interna:

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

Quell'asserzione dimostra che una proprietà esiste, non che il feature funzioni. Le snapshot piccole e 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-native, con versione 13.3.3 pubblicata nel 2026, secondo le informazioni del repository . Le convenzioni di query condivise aiutano all'interno di piattaforme, ma non decidono quale asserzione rappresenta il comportamento del prodotto.Preferisci le asserzioni specifiche alle snapshot

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

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

Modelli pratici per i componenti, gli hook e la navigazione

Un insieme di test 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.

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

Etichetta esatta che corrisponde 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 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');

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

La navigazione e i dati asincroni

Per il comportamento di navigazione, la rendering di una schermata all'interno di una reale NavigationContainer e un piccolo navigatore di test è spesso più utile del mock di ogni metodo di navigazione. Premi un controllo visibile, aspetta il contenuto di destinazione e assicurati che lo schermo nuovo abbia un output. Un mock diretto è ancora appropriato per un piccolo bottone il cui unico compito è inviare una rotta tipizzata, ma non verificherà la registrazione della rotta, i parametri o il comportamento del navigatore nidificato. useNavigation Il dati asincroni meritano la stessa disciplina. Mocka la risposta del repository o __CAPGO_KEEP_0__, rendera la schermata, assicurati lo stato di caricamento, risolvi la richiesta, quindi assicurati l'output di successo o errore. Utilizza

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 Il mock dei moduli nativi

Il mock per AsyncStorage, le autorizzazioni, le telecamere, i biometri e le API di piattaforma sono utili per le prove di JavaScript deterministiche. Non sono una prova che la funzione nativa funziona. Mantieni il comportamento del mock vicino al contratto del modulo, resetta le chiamate tra le prove e include le risposte di fallimento al posto di modellare solo la via felice.

Scenario

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

Verifica dei Test Instabili, Controlli di Prestazioni e CI

Un test instabile spesso indica un tempo non controllato, uno stato condiviso o un'asserzione che si svolge in parallelo con l'interfaccia utente. Identifica la condizione presente prima di aumentare i 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 di 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. act La raccomandazione significa che React ha osservato un aggiornamento fuori dal suo limite di interazione previsto. Correggi la mancanza di interazione utente o di timer di pulizia al posto di sopprimere la raccomandazione. awaitRendi 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 di dipendenza o di configurazione richiedono una validazione della cache appropriata.

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

L'osservabilità copre un diverso gap. Uno strumento come

Sentry per React Native fornisce il contesto degli errori di produzione che i test dei componenti mockati non possono riprodurre, compresi gli errori legati ai dispositivi reali e alle integrazioni native. Gli itinerari sensibili alla sicurezza richiedono un secondo limite. Utilizza i test dei componenti per la validazione e le transizioni di stato, quindi aggiungi la copertura a livello di dispositivo per la consegna e il comportamento native. Per le flussi one-time-__CAPGO_KEEP_0__, consulta la guida su come

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 quando quella integrazione fa parte del percorso. Tieni la prestazione come misura, non come affermazione

warning significa che React ha osservato un aggiornamento fuori dal suo limite di interazione previsto. Correggi la mancanza di interazione utente o di timer di pulizia al posto di sopprimere la raccomandazione.

A un test funzionale si può confermare che una lista viene visualizzata. Non può determinare in modo affidabile se un refactoring ha cambiato la durata della renderizzazione o il conteggio della renderizzazione, perché il tempo di esecuzione del test aggiunge rumore. Le misure rassicurano i valori per uno scenario, ripete lo scenario per ridurre la varianza e applica l'analisi statistica prima di segnalare un cambiamento significativo. La documentazione di testing di prestazioni Anche copre la relazione dei dati adatti per la revisione di CI e pull-request.

Evita le affermazioni fisse come “questa 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 misure ripetute per i segnali di regressione, poi ispeziona il componente e il profilo del dispositivo quando la comparazione mostra una differenza significativa.

Regola di misura: Il test funzionale risponde se il comportamento è corretto. Gli strumenti di prestazioni rispondono se uno scenario misurato è cambiato. Tieni separate queste domande.

Mettilo insieme e muoviti avanti

La React Native Testing Library appartiene alla vasta, 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. Tieni questi test concentrati 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 renderizzazione.

La layer più piccola basata sul dispositivo dovrebbe proteggere i flussi dove i mock possono ingannare. La visione di testing di React Native affermato 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 flussi critici, inclusi l'autenticazione, i pagamenti e la funzionalità di base dell'applicazione.

Un percorso di migrazione pratico

Non è necessario riscrivere un insieme esistente in un'unica passata.

1. Conserva i test aziendali preziosi. Sposta la logica di stato e di dominio in test unitari focalizzati dove forniscono feedback chiaro.
2. Sostituisci le affermazioni di implementazione per primo. Cambia le verifiche delle proprietà e dello stato interno in 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 native. Per ogni modulo mockato importante, identifica il comportamento del dispositivo che ancora richiede la 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. Utilizza confronti di prestazioni ripetuti per le liste, i feed e le percorsi di rendering costosi al posto di supporre sulla durata di Jest.

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 JavaScript o di asset deve raggiungere gli utenti dopo la validazione, __CAPGO_KEEP_0__ 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 dispositivo React Native, ma illustra lo stesso principio: valuta il comportamento al livello in cui si esegue. and require the appropriate test layer before shipping. If a JavaScript or asset fix must reach users after validation, Capgo can deliver signed web bundles to targeted channels for CapacitorJS and Electron applications, with rollout controls and rollback protection. That delivery workflow doesn’t replace React Native device tests, but it illustrates the same principle: validate behavior at the layer where it runs.

__CAPGO_KEEP_0__ collega i cambiamenti JavaScript e di asset validati alla consegna controllata per le squadre CapacitorJS e Electron, con canali mirati, visibilità di rollout e protezione del rollback. Visita

Capgo Capgo Scritto da