React Native Testing Library: Wie Sie Apps richtig testen

Sein React Native-Test-Suite ist grün, aber ein Benutzer meldet, dass das Klicken auf „Weiter“ auf einem echten Gerät nichts tut. Der Komponententest fand den Button, rief seinen Handler auf und sah die erwartete Bildschirmansicht in einem mockierten JavaScript-Umgebung. Er überprüfte jedoch nie die native Berechtigungsanfrage, die Tastaturverhalten, die Animation, die Plattform API oder den tatsächlichen Navigationsstapel.

Dass Lücke ist, wo Teams falsche Zuversicht bekommen. React Native Testbibliothek ist hervorragend für die Überprüfung dessen, was eine Komponente renderet und wie sie auf Benutzereingaben reagiert, aber es ist kein Ersatz für Geräte-Tests oder Leistungsmessungen. Die zuverlässige Strategie besteht darin, jede Schicht für die Fehler zu verwenden, die sie aufdecken kann.

Inhaltsübersicht

• Warum Benutzerzentrierte Tests alles verändern
  • Wie Benutzerzentrierte Tests alles ändern
  • Weißt, was erfolgreiche Tests beweisen
• Wissen Sie, was sichere Tests nicht beweisen
  • Installation und Konfiguration, die tatsächlich funktioniert
• Halten Sie die Setup-Dateien explizit
  • Wählen Sie die Abfrage nach Zeit und Absicht
  • Verwenden Sie spezifische Behauptungen anstelle von Snapshots
• Praktische Muster für Komponenten, Hooks und Navigation
  • Darstellende Komponenten
  • Navigation und asynchrone Daten
  • Mocks für native Module
• Debugging von fluktuierenden Tests, CI und Leistungsüberprüfungen
  • Stellen Sie CI-Fehler wiederherstellbar ein
  • Behandeln Sie Leistung als Messwert, nicht als Behauptung
• Alles zusammenfassend und vorwärts
  • Ein praktischer Weg zur Migration

Weshalb Benutzerzentrierte Tests alles verändern

A häufige Testfehler beginnt, bevor der Test geschrieben wird. Ein Entwickler untersucht die Komponente, greift in ihren Zustand ein oder vergleicht einen großen Snapshot, weil diese Details leicht zu überprüfen sind. Der Test besteht, dann ändert ein Refactoring die Komponentenstruktur ohne die Erfahrung zu ändern und die Suite bricht zusammen. Schlimmer noch, der Test kann weiterhin bestehen, während die Benutzererfahrung falsch ist, weil die Überprüfung nie beschreibt, was der Benutzer sehen muss.

Die React Native Testing Library nimmt das Gegenteil an. Sie rendern die Komponente, interagieren mit ihr über eine sichtbare Steuerung und überprüfen dann das Ergebnis, das der Benutzer beobachten kann. Diese Ansicht entspricht Beispiel für die React Native Testing Libraryund den Testleitfäden von React Native, die kurze Tests empfehlen, jeden Test auf ein Thema konzentrieren, die Ansichten von der Geschäftslogik und dem Zustand trennen und die sichtbare Ausgabe oder die Barrierefreiheit vor den internen Implementierungsdetails bevorzugen.

Prüfe die vom Benutzer erwartete Funktionalität

Stellen Sie sich vor, ein Login-Formular deaktiviert seinen Absenden-Button, während ein Anfrage läuft. Ein brüchiger Test könnte disabled auf eine bestimmte Komponenteninstanz oder überprüfen, ob eine Zustandsvariable geändert wurde. Ein stärkerer Test drückt die zugängliche "Anmelden"-Schaltfläche, wartet auf den Ladeindikator und überprüft, ob ein Fehlermeldung oder die Zielbildschirm erscheint.

Der zweite Test kümmert sich nicht darum, ob die Form lokale Zustände, einen Reducer, einen benutzerdefinierten Hook oder eine andere Schaltflächenerstellung verwendet.

Praktische Regel: Wenn ein Benutzer es nicht beobachten kann, fragen Sie sich, ob es in einem Komponentenverhaltens-Test gehört.

Abfragen auf der Grundlage von Barrierefreiheitsbezeichnungen und -rollen zwingen auch zu einem besseren Produkt code. Eine Bildschirmoberfläche, die sinnvolle Bezeichnungen enthüllt, ist einfacher zu bedienen mit assistiven Technologien und einfacher zu testen. Diese Verbindung ist wichtig, wenn Sie die umfassendere Benutzererfahrung des Appserfassen, weil Testbarkeit und Benutzbarkeit oft zusammen verbessert werden.

Weißt, was ein erfolgreiches Testergebnis beweist

Ein benutzerzentrierter Komponenten-Test kann beweisen, dass JavaScript die erwartete Verzweigung rendern und auf eine simuliert gedrückte Taste reagieren kann. Er kann jedoch nicht beweisen, dass ein biometrischer Prompt richtig geöffnet wird, dass eine native Kamera einen verwendbaren Ergebnis liefert oder dass eine Zahlungsabwicklung durch Plattform-spezifische Lebenszyklusverhalten überlebt.

Dieser Grenzbereich ist keine Schwäche der Bibliothek. Es ist ein Grund, die Testebenen ehrlich zu halten. Verwenden Sie RNTL für Komponentenverhalten, reservieren Sie dann Geräte-basierte Tests für Flüsse, bei denen native Integration, echte Navigation, Berechtigungen, Authentifizierung, Zahlungen oder Kernfunktionen der App den Ausgang beeinflussen können.

Installation und Konfiguration, die tatsächlich funktioniert

Moderne Einrichtung beginnt mit dem skalierten Paket:

@testing-library/react-native

Die ältere react-native-testing-library npm Paketname existiert noch als historisches Artefakt, aber aktuelle Projekte sollten das im Testing Library-Familienbereich gehaltene skalierte Paket verwenden. Das Projekt’s GitHub Repository beschreibt es als React Native-Hilfsmittel für die Förderung guter Testpraktiken, und seine Veröffentlichungsgeschichte zeigt, dass die Bibliothek weiterhin mit React Native geändert wurde, anstatt ein statisches Hilfsmittel zu bleiben.

Installieren Sie die Bibliothek mit Ihrem bestehenden Jest-Umgebung. Expo-Projekte verwenden häufig den Expo Jest-Preset, während bare React Native-Projekte den React Native-Preset verwenden können:

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

Für Expo fügen Sie den von Ihrem Projekt bereits verwendeten Preset hinzu:

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

Für ein bare React Native-Anwendungsprojekt verwenden Sie stattdessen die entsprechende React Native Jest-Konfiguration. Halten Sie den Preset mit der Frameworkversion im Einklang. Viele Fehler, die wie RNTL-Probleme aussehen, kommen von einem nicht übereinstimmenden React-Renderer, Babel-Transform oder Jest-Preset.

Halten Sie die Setup-Dateien explizit

Legen Sie gemeinsame Umgebungsconfigurations in einer Setup-Datei ab, anstatt in jedem Test Mocks zu wiederholen:

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

Verweisen Sie dann auf Jest:

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

Wenn Ihr App React Navigation, Reanimated, gesture handling, safe-area Kontext oder Speichermodul verwendet, konfigurieren Sie nur die Mocks, die Ihre Testumgebung benötigt. Ein globaler Mock, der die Anwendungsverhalten ändert, kann jeden Test einfacher machen, während die Suite weniger vertrauenswürdig wird.

TypeScript benötigt die gleiche Aufmerksamkeit. Stellen Sie sicher, dass Jest-Transforms .ts und .tsx Dateien werden über die vordefinierte Einstellung oder Ihre Babel-Konfiguration durchgeführt und halten Testtypen für den Compiler bereit. Ein lokal ausgeführter Test, der nicht durch Typen überprüft wird, kann falsche Abfragebezeichnungen, ungültige Navigationsparameter oder unsichere Mock-Formen verbergen.

Die Veröffentlichungschronologie ist nützlich, wenn ältere Einrichtungshinweise diagnostiziert werden müssen. Die Projektliste 127 Veröffentlichungen, mit v14.0.1, am 23. Juni 2026 markiert, während v12.9.0, veröffentlicht am 27. November 2024, fügte offizielle Unterstützung für React Native 0.77 und Expo 52 hinzu.. Die v14-Alpha-Linie im März 2025 wechselte zum Universal Test Renderer von dem veralteten React Test Renderer und bereitete sich auf die Unterstützung für React 19 nur vor. Diese Details sind im RNTL-Veröffentlichungsverlaufersichtlich, daher sollten Sie nicht ohne Überprüfung Ihrer App-Versionen eine Renderer-Abhängigkeit aus einem veralteten Tutorial kopieren.

Für eine praktische Jest-Grundlage vergleichen Sie Ihre Konfiguration mit diesem Jest-Einheitstestleitfaden Dann führen Sie eine kleine Komponententest durch, bevor Sie Navigations- und native Mocks hinzufügen.

Erklärung der Kern-APIs, Abfragen und Behauptungen.

RNTL-Tests werden vertrauenswürdig, wenn ihre Abfragen mit dem, was ein Benutzer sehen, finden und bedienen kann, übereinstimmen. Der API ist klein, aber die Wahl eines Selektors, der Implementierungsdetails offenlegt, kann einen erfolgreichen Test irreführend machen.

Beginnen Sie mit render:

const screen = render(<LoginForm />);

Wählen Sie die am besten geeignete Benutzerrelevanz-Abfrage. Preferieren Sie abrufbare Abfragen, wenn das Komponenten sie offenlegt, verwenden Sie sichtbares Text, wenn Text das Verhalten ist, und reservieren Sie testID für Fälle ohne einen bedeutenden Benutzerfokus-Selektor oder wo eine stabile Integrationsschleife benötigt wird.

Wählen Sie die Abfrage nach Zeit und Absicht

Jede Abfragen-Familie hat einen bestimmten Zweck:

• Synchroner Anwesenheit: Use getByRole, getByText, oder ein anderes getBy Überprüfe, ob das Element bereits existiert. Der Test scheitert sofort, wenn es nicht existiert.
• Asynchrone Erscheinung: Use findByRole oder findByText wenn das Rendern oder die Interaktion eine asynchrone Aktualisierung auslöst.
• Abwesenheitsprüfungen: Use queryByText oder queryByTestId wenn ein Element fehlen kann und stattdessen ein Null-Ergebnis erwartet wird anstatt einer Exception.
• Fallback Selektoren: Use getByTestId bewusst. Es gibt komplexen Steuerungen einen dauerhaften Haken, sollte aber nicht die zugänglichen Beschriftungen im gesamten App ersetzen.

Für fokussierte Ereignistests: fireEvent.press ist direkt:

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

Verwende userEvent wenn die installierte Version die realistischere Interaktionssequenz unterstützt. Auf jeden Fall solltest du das resultierende UI bestätigen:

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

Eine Handler-Assertion passt sich einem Komponenten an, dessen öffentlicher Vertrag ein Ereignisrückruf ist. Sie ist schwach, da sie der einzige Beweis dafür ist, dass die Benutzerreise funktioniert.

Präferiere spezifische Aussagen gegenüber Snapshots

Gute Aussagen beschreiben das Bildschirm:

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

Sie können auch die Barrierefreiheit, die Auswahl und die sichtbare Validierungsfeedback überprüfen. Internes Abhängigkeitsprüfen vermeiden.

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

Diese Aussage beweist, dass eine Eigenschaft existiert, nicht, dass die Funktion funktioniert. Kleine, absichtliche Snapshots können Strukturänderungen erfassen, während große Navigation oder Bildschirm-Snapshots oft laute Bewertungen und unerklärte Updates erleichtern.

Das Testing-Library-Paket gehört zur breiteren testing-library npm Organisation. Zu ihren aktiven Paketen gehören @testing-library/react-nativemit Version 13.3.3 im Jahr 2026 veröffentlichtnach Angaben des Projekts Repository-InformationenGeteilte Abfragekonventionen helfen über Plattformen hinweg, entscheiden aber nicht, welche Behauptung Ihr Produktverhalten darstellt.

Für eine umfassendere Vergleichbarkeit von Jest-Komponententestpraktiken siehe diese Anleitung zum Einheitstesten von ReactRNTL hält sich noch am JavaScript-generierten Komponentengrenze fest. Native-Berechtigungen, echte Navigationsschichten, Gerätekonsole, Frame-Zeit und Speicherverhalten benötigen E2E- oder Leistungstools anstatt mehr Komponentenmocker.

Der folgende Video zeigt die Abfrage- und Behauptungsworkflow im Kontext.

Praktische Muster für Komponenten, Hooks und Navigation

Ein nützliches Test-Suite folgt der Form des Anwendungsprogramms. Präsentationskomponenten benötigen direkte Verhaltensprüfungen, Hooks benötigen kontrollierte Eingänge und Ausgänge, Navigation benötigt einen realistischen genug bereitgestellten Anbieter und native Module benötigen Mocker, die sichtbar anders sind als die Überprüfung auf echte Geräte.

Darstellungs-Komponenten

Halten Sie einen Komponenten-Test in der Nähe seines öffentlichen Vertrags:

const onSelect = jest.fn();

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

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

expect(onSelect).toHaveBeenCalled();

Der genaue Label sollte dem UI entsprechen. Die wichtige Sache ist, dass der Test den Kontrollelement finden kann, wie ein Benutzer oder eine Barrierefreiheit-Dienst und bestätigt, dass die sichtbare oder Callback-Ausgabe relevant ist. Mocken Sie nicht jede Kind-Komponente standardmäßig. Mocken Sie nur teure oder unabhängige Grenzen, wenn sie das zu testende Verhalten verdecken.

Für eine benutzerdefinierte Hook verwenden Sie renderHook wenn die installierte RNTL-Version es bietet:

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

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

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

Der Hook-Test sollte die Netzwerk- oder Repository-Grenze steuern, nicht die gesamte App reproduzieren. Testen Sie die Seite separat, um zu wissen, ob der Hooks-Zustand nützlich wird.

Navigation und asynchrone Daten

Für die Navigation verhalten, ist es oft wertvoller, eine echte NavigationContainer und einen kleinen Test-Navigator zu rendern, anstatt jede Navigation-Methode zu mocken. Drücken Sie eine sichtbare Steuerung, warten Sie auf das Ziel-Inhalt und bestätigen Sie die neue Seite-Ausgabe. Ein direkter useNavigation Mock ist immer noch geeignet für einen kleinen Button, dessen einzige Verantwortung darin besteht, einen getippten Routen zu dispatchen, aber es wird nicht die Routen-Registrierung, Parameter oder das Verhalten des inneren Navigators überprüfen.

Asynchrone Daten verdienen denselben Disziplin. Mocken Sie die API oder den Repository-Antwort, rendern Sie die Seite, bestätigen Sie den Ladezustand, lösen Sie die Anfrage auf und bestätigen Sie dann Erfolg oder Fehler-Ausgabe. Verwenden Sie findBy Fragen für die erwarteten zukünftigen Elemente und machen Sie abgelehnte Anfragen explizit, ansonsten kann ein Test erfolgreich sein, weil die Komponente nie den gewünschten Zweig erreicht.

Native Modul-Mocks

Mocks für AsyncStorage, Berechtigungen, Kameras, Biometrie und Plattform-APIs sind nützlich für deterministische JavaScript-Tests. Sie sind jedoch kein Beweis dafür, dass die native Funktion funktioniert. Halten Sie das Mock-Verhalten nahe am Modulvertrag, setzen Sie Aufrufe zwischen Tests zurück und beinhalten Sie Fehlerantworten anstatt nur den glücklichen Weg zu modellieren.

Die Grenze ist praktisch: Mocken Sie die Abhängigkeit, um Ihre JavaScript-Entscheidungen zu testen, und führen Sie dann ein Geräte-Test durch, um die tatsächliche Verhaltensweise der Abhängigkeit zu bestätigen.

Fehlende Tests CI und Leistungskontrollen

Ein unzuverlässiger Test deutet oft auf unkontrollierte Zeit, geteilte Zustände oder eine Behauptung hin, die sich mit der Benutzeroberfläche auseinandersetzt. Identifizieren Sie, welches Problem vorliegt, bevor Sie Zeitspannen erhöhen. Eine längere Zeitspanne kann das Schedulingproblem verbergen und die Suite langsamer machen.

Use findBy für Elemente, die nach einer Aktualisierung auftauchen sollen. Verwenden Sie waitFor für Zustandsbedingungen oder Mockaufrufe. Wenn fiktive Timer aktiviert sind, setzen Sie sie an dem Punkt fort, an dem die Interaktion erforderlich ist, und setzen Sie die echten Timer danach wieder her. Ein act warning means React observed an update outside its expected interaction boundary. Fix the missing awaitBenutzerinteraktion oder Timerflush anstatt die Warnung zu unterdrücken.

Machen Sie CI-Fehler wiederholbar

Ein zuverlässiger CI-Auftrag installiert sich aus dem Lockfile, führt den gleichen Jest-Befehl aus, der lokal verwendet wird, und isoliert Mock-Zustände. Lösen Sie Mockaufrufe zwischen Tests auf, setzen Sie Module zurück, wenn Modul-Zustände das Verhalten beeinflussen, und entfernen Sie Abhängigkeiten von der Ausführungsreihenfolge. Die Caching-Funktion von Jest beschleunigt die Rückmeldung, aber Abhängigkeiten oder Konfigurationsänderungen erfordern eine angemessene Cacheinvalidierung.

CI-spezifische Fehler benötigen eine Umgebungsvergleichung vor einer Komponentenüberarbeitung. Überprüfen Sie Node, den Paketmanager, die Jest-Arbeitereinstellungen, die Timer-Konfiguration und die Umgebungsvariablen. Reproduzieren Sie den gleichen Befehl lokal, wo immer möglich, und reduzieren Sie den fehlenden Test auf die kleinste Interaktion, die den Unterschied aufzeigt.

Beobachtbarkeit deckt einen anderen Bereich ab. Ein Werkzeug wie Sentry für React Native Liefert Kontext für Produktionsfehler, der von getesteten Komponenten nicht nachgemacht werden kann, einschließlich Fehlern, die mit realen Geräten und nativen Integrations zusammenhängen.

Sicherheitsrelevante Reisen benötigen eine zweite Grenze. Verwenden Sie Komponententests für die Validierung und die Zustandsübergänge, fügen Sie dann Geräebene Abdeckung für die Handover und die nativen Verhaltens hinzu. Für einmalige code-Flüsse, konsultieren Sie die Anleitung, wie man SMS-Verifizierungsflüsse testen kann wenn diese Integration Teil des Reises ist.

Leistung als Messung, nicht als Behauptung behandeln

Ein funktioneller Test kann bestätigen, dass eine Liste gerendert wird. Er kann jedoch nicht zuverlässig bestimmen, ob eine Umstrukturierung die Renderdauer oder die Renderanzahl geändert hat, weil der Testlauf Rauschen hinzufügt. Überzeugen Sie sich, dass die Werte für ein Szenario, wiederholen Sie das Szenario, um die Varianz zu reduzieren und führen Sie eine statistische Analyse durch, bevor Sie einen bedeutenden Wechsel melden. Seine Leistungstestdokumentation umfasst auch Berichterstattung, die für CI und Pull-Request-Überprüfungen geeignet ist.

Vermeiden Sie feste Behauptungen wie „Dieser Render muss unter einer gewählten Grenze liegen.“ Ein beschäftigter CI-Arbeiter kann einen falschen Fehler auslösen, während ein lockerer Schwellenwert einen realen Rückschritt verpasst. Verwenden Sie wiederholte Messungen für Rückschrittsignale, dann inspizieren Sie die Komponente und das Geräeprofil, wenn der Vergleich einen bedeutenden Unterschied zeigt.

Messungsregel: Funktionale Tests beantworten, ob das Verhalten richtig ist. Leistungsanzeige beantwortet, ob ein gemessenes Szenario geändert wurde. Halten Sie diese Fragen getrennt.

Alles zusammenfassend und Vorwärtsgehen

React Native Testing Library gehört in den breiten, schnellen Layer Ihrer Teststrategie. Es sollte das Verhalten von Komponenten, sichtbare Zustandsänderungen, Zugänglichkeitsausgänge, Validierung, mockierte Datenzustände und die Integration zwischen JavaScript-Komponenten abdecken. Halten Sie diese Tests auf das Fassbare, was ein Benutzer beobachten kann, und machen Sie Fehler auf ein bestimmtes Verhalten hinweisen, anstatt auf eine große Render-Tree.

Der kleinere Geräte-basierte Layer sollte die Flüsse schützen, wo Mocks liegen können. React Native’s Testüberblick erklärt, dass RNTL kein vollständiges React Native Runtime bereitstellt und keine nativen Funktionen testen kann. Die gleiche Anleitung empfiehlt, Komponententests mit E2E-Tools wie Detox zu kombinieren, um kritische Flüsse wie Authentifizierung, Zahlungen und Kernfunktionen der App zu testen.

Ein praktischer Migrationsweg

Sie müssen Ihre bestehende Suite nicht in einem Durchgang umschreiben.

1. Halten Sie wertvolle Geschäfts-Tests. Verschieben Sie reine Zustands- und Domänenlogik in fokussierte Einheitstests, wo sie klare Feedback geben.
2. Ersetzen Sie Implementierungsanforderungen zuerst. Ändern Sie Prop- und internen-Zustandsprüfungen in sichtbare Ausgaben, Zugänglichkeitszustände und Interaktionsausgänge.
3. Verkleinern Sie Snapshots. Behalten Sie nur Snapshots bei, die Reviewer verstehen und pflegen können.
4. Native Grenzen abdecken. Für jeden wichtigen mockten Modul identifizieren Sie das Geräteverhalten, das noch eine Validierung benötigt.
5. Kritische Reiserouten schützen. E2E-Abdeckung für Authentifizierung, Zahlung, Kernnavigation, Berechtigungen und andere Flüsse hinzufügen, bei denen sich die native Verhaltensweise auf das Ergebnis auswirken kann.
6. Sensiblen Bildschirmen getrennt messen. Wiederholte Leistungskomparationen für Listen, Feeds und teure Renderpfade verwenden anstatt sich auf Jest-Dauer zu verlassen.

Für Vertrauen in die Veröffentlichung, verbinden Sie die Suite mit CI/CD-Integration-Testen 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__ verbindet validierte JavaScript- und Asset-Änderungen mit kontrolliertem Lieferung für CapacitorJS- und Electron-Teams, mit Zielkanälen, Rollout-Transparenz und Rollback-Schutz. Besuchen Sie

Capgo verbindet validierte JavaScript- und Asset-Änderungen mit kontrollierter Bereitstellung für CapacitorJS- und Electron-Teams, mit zielgerichteten Kanälen, Rollout-Übersicht und Rollback-Schutz. Besuchen Sie Capgo um zu sehen, wie es sich neben Ihrem Komponenten, E2E- und CI-Testfluss einfügen kann.