React Native Testing Library: Wie Sie Apps richtig testen

Ihr Test-Suite für React Native ist grün, doch ein Benutzer meldet, dass das Klicken auf „Weiter“ auf einem echten Gerät nichts auslöst. Die Komponententest fand den Button, rief seinen Handler auf und sah die erwartete Seite in einem mockierten JavaScript-Umgebung. Er überprüfte jedoch nie die native Berechtigungsanfrage, die Tastaturverhalten, die Animation, die Plattform API oder den tatsächlichen Navigation-Stack.

Das ist der Punkt, an dem Teams falsche Zuversicht bekommen. React Native Testing Bibliothek ist hervorragend für die Überprüfung dessen, was ein Komponente rendern und wie sie auf Benutzereingaben reagiert, aber es ist kein Ersatz für Geräte-Tests oder Leistungsmessungen. Die zuverlässige Strategie ist, jede Schicht für die Fehler zu verwenden, die sie aufdecken kann.

Inhaltsverzeichnis

• Warum Benutzergerechte Tests alles verändern
  • Teste das Verhalten, auf das sich Benutzer verlassen
  • Wissen Sie, was sichere Tests nicht beweisen
• Installation und Konfiguration, die tatsächlich funktioniert
  • Halten Sie die Setup-Dateien explizit
• Erklärung der Kern-APIs, Abfragen und Behauptungen
  • Wählen Sie die Abfrage nach Zeit und Absicht
  • Präferieren Sie spezifische Behauptungen gegenüber Snapshots
• Praktische Muster für Komponenten, Hooks und Navigation
  • Präsentationskomponenten
  • Navigation und asynchrone Daten
  • Native-Modul-Mocks
• Debugging von fluktuierenden Tests, CI und Leistungsprüfungen
  • Stelle CI-Fehler wiederherstellbar ein
  • Behandle Leistung als Messwert, nicht als Behauptung
• Zusammenfassen und Vorwärtskommen
  • Ein praktischer Migrationsschritt

Weshalb Benutzerzentrierte Tests alles verändern

Ein häufiger Testfehler beginnt, bevor der Test geschrieben wird. Ein Entwickler untersucht eine Komponente, greift in ihren Zustand ein oder vergleicht einen großen Snapshot, weil diese Details leicht zu behaupten 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 Benutzer- sichtbare Verhaltensweise falsch ist, weil die Behauptung nie beschreibt, was der Benutzer sehen muss.

React Native Testing Library nimmt den gegenteiligen Ansatz. Sie rendern die Komponente, interagieren mit ihr über einen sichtbaren Steuerungsbereich und behaupten dann das Ergebnis, das ein Benutzer beobachten kann. Dieser Ansatz entspricht React Native Testing Library’s benutzerzentriertem Beispiel, sowie die Leitlinien von React Native für die Testung, um die Tests kurz zu halten, sich auf ein bestimmtes Thema zu konzentrieren, die Ansichten von den Geschäftslogik und dem Zustand zu trennen und sichtbare Ausgaben oder Hilfsmittel für die Barrierefreiheit vor internen Implementierungsdetails zu bevorzugen.

Testen Sie das Verhalten, auf das sich die Benutzer verlassen.

Stellen Sie sich vor, ein Login-Formular deaktiviert seinen Absenden-Button, während ein Anfrage läuft. Ein brüchiger Test könnte sich auf eine bestimmte Komponenteninstanz oder behaupten, dass ein Zustandsvariable geändert wurde. Ein stärkerer Test drückt den zugänglichen "Anmelden"-Knopf, wartet auf den Ladeindikator und überprüft, ob ein Fehlermeldung oder die Ziel-Seite erscheint. disabled Der zweite Test kümmert sich nicht darum, ob das Formular lokale Zustände, einen Reducer, einen benutzerdefinierten Hook oder eine andere Schaltflächenimplementierung verwendet. Er kümmert sich darum, dass die App das richtige Ergebnis kommuniziert.

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 Barrierefreiheitsetiketten und -rollen zwingen auch zu besseren Produkten. Eine Seite, die sinnvolle Etiketten enthält, ist einfacher zu bedienen mit assistiven Technologien und einfacher zu testen. Diese Verbindung ist wichtig, wenn Sie die breitere

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 bewerten, weil Testbarkeit und Benutzbarkeit oft zusammen verbessert werden.Wissen Sie, was die bestehenden Tests nicht beweisen.

__CAPGO_KEEP_0__

Ausnutzung eines benutzerzentrierten Komponententests kann beweisen, dass JavaScript die erwartete Zweig rendern und auf eine simuliert gedrückte Taste reagieren kann. Es kann jedoch nicht beweisen, dass ein biometrischer Prompt korrekt öffnet, dass eine native Kamera einen verwertbaren Ergebnis zurückgibt oder dass eine Zahlungsabwicklung auf Plattform-spezifische Lebenszyklusverhalten überlebt.

Diese Grenze ist keine Schwäche der Bibliothek. Es ist ein Grund, die Testebenen ehrlich zu halten. Verwenden Sie RNTL für die Komponentenverhalten, reservieren Sie dann Geräte-basierte Tests für Flows, bei denen native Integration, echte Navigation, Berechtigungen, Authentifizierung, Zahlungen oder Kernfunktionalität des Apps den Ausgang beeinflussen können.

Installation und Konfiguration, die tatsächlich funktioniert

Moderne Einrichtung beginnt mit dem skalierten Paket:

@testing-library/react-native

Das ältere react-native-testing-library npm Paketname existiert noch als historisches Artefakt, aber aktuelle Projekte sollten das skalierte Paket verwenden, das innerhalb der Testing Library Familie gepflegt wird. Das Projekt GitHub Repository beschreibt es als React Native-Utilitäten zur Förderung guter Testpraktiken und seine Veröffentlichungsgeschichte zeigt, dass die Bibliothek weiterhin an React Native angepasst 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 eine nackte React Native Anwendung verwenden Sie die entsprechende React Native Jest-Konfiguration. Halten Sie die Vorlage mit der Frameworkversion überein. Viele Fehler, die wie RNTL-Probleme aussehen, kommen von einem nicht übereinstimmenden React-Renderer, Babel-Transform oder Jest-Vorlage.

Halten Sie die Einstellungsdateien explizit

Legen Sie die gemeinsame Umgebungs-Konfiguration in eine Einstellungsdatei anstatt Mocks in jedem Test zu wiederholen:

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

Referenzieren Sie sie dann in Jest:

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

Wenn Ihre App React Navigation, Reanimated, Gesten-Handling, safe-Area-Kontext oder Speicher-Module verwendet, konfigurieren Sie nur die Mocks, die Ihr Testumgebung benötigt. Ein globaler Mock, der die Anwendungsverhalten ändert, kann jeden Test einfacher bestehen lassen, während die Suite weniger vertrauenswürdig wird.

TypeScript benötigt die gleiche Aufmerksamkeit. Stellen Sie sicher, dass Jest-Transforms .ts und .tsx Dateien durch die Vorlage oder Ihre Babel-Konfiguration durchgeführt werden, und halten Sie Testtypen für den Compiler verfügbar. Ein Test, der lokal ausgeführt wird, aber nicht typgeprüft wird, kann falsche Abfrage-Namen, ungültige Navigationsparameter oder unsichere Mock-Formen verbergen.

Die Veröffentlichungschronologie ist nützlich, wenn ältere Einstellungsanweisungen diagnostiziert werden. Der Projektliste 127 Veröffentlichungen, mit v14.0.1 markiert am 2026-06-23, während v12.9.0, am 27. November 2024 veröffentlicht, fügte offizielle Unterstützung für React Native 0.77 und Expo 52 hinzu. Die v14-Alpha-Version 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 vor. Diese Details finden Sie in der RNTL-Veröffentlichungsgeschichte, also überprüfen Sie nicht ohne Weiteres eine Renderer-Abhängigkeit aus einem veralteten Tutorial, ohne die Version Ihres Apps zu überprüfen.

Für eine praktische Jest-Grundlage vergleichen Sie Ihre Konfiguration mit diesem Jest-Einheitstestleitfaden, führen Sie dann einen kleinen Komponententest aus, bevor Sie die Navigation und native Mocks hinzufügen.

Core APIs Queries und Assertions erklärt

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 Benutzer relevanteste verfügbare Abfrage. Preferieren Sie Abfragen mit Bezug zur Barrierefreiheit, wenn das Komponenten diese ausgibt, verwenden Sie sichtbares Text, wenn der Text das Verhalten ist, und reservieren Sie testID den Fall ohne einen bedeutsamen Benutzer-Selektor oder wo eine stabile Integrations-Hook benötigt wird.

Wählen Sie die Abfrage nach Zeit und Absicht

Jede Abfrage-Familie hat einen bestimmten Zweck:

• Synchroner Anwesenheit: Verwenden Sie getByRole, getByText, oder eine andere getBy Abfrage, wenn das Element bereits existieren sollte. Der Test schlägt sofort fehl, wenn es nicht existiert.
• Asynchroner Erscheinung: Verwenden Sie findByRole oder eine andere Abfrage, wenn das Element noch nicht existiert. Der Test wartet, bis das Element erscheint, bevor er fortfährt. findByText Wenn das Rendern oder eine Interaktion einen asynchrone Update verursacht.
• Abwesenheitsprüfungen: Verwenden Sie queryByText oder queryByTestId Wenn Sie absichtlich eine nicht vorhandene Komponente erwarten und anstelle eines Ausnahmefalls ein Null-Ergebnis erwarten.
• Fallback-Selektoren: Verwenden Sie getByTestId Wenn Sie absichtlich eine nicht vorhandene Komponente erwarten und anstelle eines Ausnahmefalls ein Null-Ergebnis erwarten.

Wenn Sie absichtlich eine nicht vorhandene Komponente erwarten und anstelle eines Ausnahmefalls ein Null-Ergebnis erwarten. fireEvent.press Wenn Sie absichtlich eine nicht vorhandene Komponente erwarten und anstelle eines Ausnahmefalls ein Null-Ergebnis erwarten.

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

Wenn Sie absichtlich eine nicht vorhandene Komponente erwarten und anstelle eines Ausnahmefalls ein Null-Ergebnis erwarten. userEvent Wenn Sie absichtlich eine nicht vorhandene Komponente erwarten und anstelle eines Ausnahmefalls ein Null-Ergebnis erwarten. Es gibt komplexen Steuerelementen einen dauerhaften Haken, aber es sollte nicht die zugänglichen Beschriftungen im gesamten App ersetzen.

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

Ausdrücke für Handler passen sich einem Komponenten an, dessen öffentlicher Vertrag ein Ereignis-Callback ist. Sie sind schwach, da sie das einzige Beweis sind, dass die Benutzerreise funktioniert.

Präferieren Sie spezifische Ausdrücke gegenüber Snapshots

Gute Ausdrücke beschreiben das Bildschirm:

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

Sie können auch die Zugänglichkeit, die Auswahl und die sichtbare Validierungsfeedback überprüfen. Vermeiden Sie es, die internen Verbindungen zu überprüfen:

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

Dieser Ausdruck 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 zum breiteren testing-library npm-Organisation. Seine aktiven Pakete umfassen @testing-library/react-native, mit Version 13.3.3 veröffentlicht im Jahr 2026, laut der Projektinformationen im Repository. Gemeinsame Abfragesätze helfen über Plattformen hinweg, aber sie entscheiden nicht, welcher Ausdruck Ihr Produktverhalten darstellt.

Für eine umfassendere Vergleichbarkeit von Jest-Komponententestpraktiken, siehe diese Anleitung zu Einheitstests für React. RNTL hält sich jedoch noch am JavaScript-generierten Komponentengrenze auf. Native-Berechtigungen, echte Navigationsschichten, Gerätekonsole, Frame-Zeit und Speicherverhalten benötigen E2E- oder Leistungsanzeigetools anstatt mehrere Komponentenmocker.

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

Praktische Muster für Komponenten, Hooks und Navigation

Eine nützliche Testsuite folgt der Form des Anwendungsprogramms. Darstellungskomponenten benötigen direkte Verhaltensprüfungen, Hooks benötigen kontrollierte Eingänge und Ausgänge, Navigation benötigt einen realistischen genug bereitgestellten Provider und native Module benötigen Mocks, die sichtbar anders sind als die Überprüfung auf einem echten Gerät.

Darstellungskomponenten

Halten Sie einen Komponententest 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 das Steuerungselement findet, wie ein Benutzer oder eine Barrierefreiheitsservice es tun würde, und bestätigt, dass die sichtbare oder Callback-Ausgabe relevant ist. Mocken Sie nicht jede untergeordnete Komponente standardmäßig. Mocken Sie nur teure oder unabhängige Grenzen, wenn sie das Verhalten unter Test verdecken.

Für einen benutzerdefinierten 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 nachbilden. Testen Sie die Anzeige separat, um zu wissen, ob der Zustand des Hooks nützlich wird.

Navigation und asynchrone Daten

Für die Navigation verhalten, ist es oft wertvoller, eine Anzeige innerhalb eines realen und eines kleinen Testnavigators zu rendern, als jede Navigationsmethode zu mocken. Drücken Sie einen sichtbaren Steuerung, warten Sie auf das Zielinhalts und bestätigen Sie die Ausgabe der neuen Anzeige. Ein direkter Mock ist immer noch geeignet für einen kleinen Button, dessen einzige Aufgabe darin besteht, einen typisierten Routenwert zu versenden, aber er wird die Routenregistrierung, die Parameter oder die verarbeitete Navigationsverhalten nicht überprüfen. NavigationContainer Asynchrone Daten verdienen denselben Disziplin. Mocken Sie den __CAPGO_KEEP_0__ oder den Repository-Antwort, rendern Sie die Anzeige, bestätigen Sie den Ladezustand, lösen Sie die Anfrage auf und bestätigen Sie dann Erfolg oder Fehlerausgabe. Verwenden Sie Anfragen für die erwarteten zukünftigen Elemente und machen Sie abgelehnte Anfragen explizit, ansonsten kann ein Test erfolgreich sein, weil der Komponente nie die beabsichtigte Verzweigung erreicht. useNavigation Native-Modul-Mocks

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 Szenario

Beste mit RNTL

Braucht E2E-Validierung

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.

Fehlertests, CI- und Leistungsprüfungen

Ein Fehlertest deutet oft auf unkontrollierte Zeit, gemeinsame Zustände oder eine Behauptung hin, die sich mit der Benutzeroberfläche auseinandersetzt. Identifizieren Sie, welches Problem vorliegt, bevor Sie Zeitüberschreitungen einräumen. Ein längeres Timeout kann das Schedulingproblem verbergen und die Suite langsamer machen.

Verwenden Sie findBy für Elemente, die nach einer Aktualisierung erscheinen 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 realen Timer danach wieder her. act Warnungen bedeuten, dass React eine Aktualisierung außerhalb seiner erwarteten Interaktionsgrenze beobachtet hat. Beheben Sie das Fehlende await, Benutzerinteraktion oder Timer-Flush anstatt die Warnung zu unterdrücken.

Stellen Sie CI-Fehler wiederherstellbar ein.

Eine zuverlässige CI-Aufgabe installiert aus dem Lockfile, führt denselben Jest-Befehl aus, der lokal verwendet wird, und isoliert den Mock-Zustand. Lösen Sie Mock-Aufrufe zwischen Tests auf, resetten Sie Module, wenn der Modul-Zustand das Verhalten beeinflusst, 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 geeignete Cache-Invalidierung.

CI-spezifische Fehler benötigen eine Umgebungsvergleichung vor einer Komponenten-Umstellung. Überprüfen Sie Node, den Paket-Manager, die Jest-Arbeitsschritte, die Timer-Konfiguration und die Umgebungsvariablen. Reproduziere denselben Befehl lokal, wo immer möglich, und reduziere den fehlenden Test auf die kleinstmögliche Interaktion, die den Unterschied aufzeigt.

Beobachtbarkeit deckt einen anderen Riss ab. Ein Werkzeug wie Sentry für React Native bietet Produktionsfehlerkontext, der von gemockten Komponententests nicht wiederhergestellt werden kann, einschließlich Fehler, die mit realen Geräten und nativen Integrations zusammenhängen.

Sicherheitskritische Reiserouten benötigen eine zweite Grenze. Verwenden Sie Komponententests für die Validierung und Zustandsübertragungen, und fügen Sie dann Geräteebene-Kovierung hinzu, um die Handover und die nativen Verhaltensweisen abzudecken. Für einmalige code-Flüsse wenden Sie sich an die Anleitung, wie man SMS-Verifizierungsflüsse testen kann zu testen, wenn diese Integration Teil der Reiseroute ist.

Behandeln Sie Leistung als Messung, nicht als Behauptung.

Aktionsbarkeitstests können bestätigen, dass eine Liste angezeigt wird. Sie können jedoch nicht zuverlässig bestimmen, ob eine Überarbeitung die Renderdauer oder die Renderanzahl geändert hat, da die Testdauer Rauschen hinzufügt. Messungen, die diese Werte für ein Szenario überprüfen, das Szenario wiederholen, um die Varianz zu reduzieren, und statistische Analysen durchführen, bevor sie einen bedeutsamen Unterschied melden. Leistungsprüfungsdokumentation 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 echten Rückschritt verpasst. Verwenden Sie wiederholte Messungen für Rückschritte, dann inspizieren Sie das Komponenten- und Geräteprofil, wenn die Vergleichszeichenfolge einen bedeutsamen Unterschied zeigt.

Regel der Messung:

Funktionsprüfungen beantworten, ob die Verhaltensweise richtig ist. Leistungsprüfungen beantworten, ob ein gemessenes Szenario geändert wurde. Halten Sie diese Fragen getrennt. Zusammenfassung und Fortschritt

React Native Testing Library gehört in die breite, schnelle Layer Ihrer Teststrategie. Sie sollte das Komponentenverhalten, die sichtbaren Zustandsänderungen, die Barrierefreiheitsergebnisse, die Validierung, die simulierten Datenzustände und die Integration zwischen JavaScript-Komponenten abdecken. Halten Sie diese Tests auf das Fokussieren, was ein Benutzer beobachten kann, und machen Sie die Fehler auf eine bestimmte Verhaltensweise hinweisen, anstatt auf eine große Renderbaumstruktur.

Die kleinere Gerätebasierte Layer sollte die Flüsse schützen, wo Mocks liegen können. React Native’s

Testübersicht Die kleineren Gerätebasierte Layer sollte die Flüsse schützen, wo Mocks liegen können. React Native’s behauptet, dass RNTL keine vollständige React Native- Runtime bereitstellt und native Funktionen nicht testen kann. Die gleichen Richtlinien empfehlen die Kombination von Komponententests mit E2E-Werkzeugen wie Detox für kritische Flüsse, einschließlich Authentifizierung, Zahlungen und Kernfunktionen der App.

Eine praktische Migrationsoption

Sie müssen ein bestehendes Suite nicht in einem Durchgang umschreiben.

1. Halten Sie wertvolle Geschäftsprüfungen. Verschieben Sie reine Zustands- und Domänelogik in fokussierte Einheitstests, wo sie klare Feedback geben.
2. Ersetzen Sie Implementierungsanweisungen zuerst. Ändern Sie Prüfungen für Eigenschaften und internen Zustände in sichtbare Ausgaben, Barrierefreiheit, Zustand und Interaktionsausgänge.
3. Kleinere Snapshots. Behalten Sie nur Snapshots bei, die Rezensenten verstehen und pflegen können.
4. Fügen Sie native Grenzbedeckungen hinzu. Für jeden wichtigen mockten Modul identifizieren Sie das Geräteverhalten, das noch eine Validierung benötigt.
5. Sichern Sie kritische Reisen. Für die E2E-Abdeckung fügen Sie die Authentifizierung, Zahlungsabwicklung, die Kernnavigation, die Berechtigungen und andere Flüsse hinzu, bei denen sich die native Verhaltensänderung auf das Ergebnis auswirken kann.
6. Messsen Sie sensible Bildschirme separat. Verwenden Sie wiederholte Leistungskomparationen für Listen, Feeds und teure Render-Pfade anstatt, dass Jest-Dauer zu erraten versucht.

Führen Sie die Suite für die Vertrauenswürdigkeit der Veröffentlichung mit der CI/CD-Integrationstestung zusammen und verlangen Sie die entsprechende Testebene vor der Versendung. Wenn ein JavaScript- oder Asset-Fix nach der Validierung an die Benutzer gelangen muss, kann __CAPGO_KEEP_0__ signierte Web-Bundles an die Zielkanäle für CapacitorJS- und Electron-Anwendungen liefern, mit Rollout-Kontrollen und Rollback-Schutz. Diese Lieferungsweg ersetzt die React Native-Geräte-Tests nicht, aber er illustriert den gleichen Grundsatz: Validieren Sie das Verhalten an der Ebene, an der es läuft. Die richtige Frage ist nicht, ob die React Native Testing Library Ihr gesamtes App testen kann. Sie kann es nicht, und die offizielle Grenze ist nützlich. Die richtige Frage ist, ob jeder wichtige Risiko einen Test in der Umgebung hat, der es offenlegt. Capgo verbindet die validierten JavaScript- und Asset-Änderungen mit der kontrollierten Lieferung für CapacitorJS- und Electron-Teams, mit Zielkanälen, Rollout-Transparenz und Rollback-Schutz. Besuchen Sie Capgo

um zu sehen, wie es sich neben Ihrem Komponenten, E2E- und CI-Testworkflow einfügen kann.

Capgo connects validated JavaScript and asset changes to controlled delivery for CapacitorJS and Electron teams, with targeted channels, rollout visibility, and rollback protection. Visit Capgo Unterstützt von