Bagaimana Menguji Aplikasi dengan React Native Testing Library

Test suite React Native Anda berwarna hijau, namun pengguna masih melaporkan bahwa mengetuk tombol “Lanjutkan” tidak berfungsi pada perangkat nyata. Test komponen menemukan tombol, memanggil handler, dan melihat layar yang diharapkan dalam lingkungan JavaScript yang dimock. Namun, tidak pernah memverifikasi prompt izin native, perilaku keyboard, animasi, platform API, atau stack navigasi yang sebenarnya.

Kesalahan itu adalah di mana tim mendapatkan kepercayaan palsu. Perpustakaan Pengujian React Native adalah sangat baik untuk menguji apa yang komponen render dan bagaimana komponen bereaksi terhadap interaksi pengguna, namun tidak dapat menggantikan pengujian perangkat atau pengukuran kinerja. Strategi yang dapat diandalkan adalah menggunakan setiap lapisan untuk kegagalan yang dapat terpapar.

Tabel Konten

• Kenapa Pengujian Berpusat pada Pengguna Mengubah Semua
  • Uji perilaku yang dipercayai pengguna
  • Tahu apa yang dibuktikan oleh tes yang berhasil
• Pemasangan dan Konfigurasi yang Benar-Benar Berfungsi
  • Jagalah file konfigurasi eksplisit
• API Utama, Kueri, dan Asertasi yang Dijelaskan
  • Pilih query berdasarkan waktu dan niat
  • Lebih baik menggunakan asertasi spesifik daripada snapshot
• Polanya yang Praktis untuk Komponen, Hooks, dan Navigasi
  • Komponen Presentasional
  • Navigasi dan Data Asinkron
  • Menggunakan Mock Modul Native
• Mengatasi Kesalahan Flaky, CI, dan Periksa Kinerja
  • Pastikan Kesalahan CI dapat direproduksi
  • Anggap Kinerja sebagai Pengukuran, bukan Asertasi
• Menggabungkan Semua dan Melangkah Maju
  • Jalur Migrasi yang Praktis

Mengapa Pengujian Berpusat pada Pengguna Mengubah Semua

A gagasan kegagalan tes biasanya dimulai sebelum tes itu ditulis. Seorang pengembang memeriksa sifat komponen, mencapai keadaannya, atau membandingkan snapshot besar karena detail-detail itu mudah untuk diuji. Tes itu melewati, kemudian refactor mengubah struktur komponen tanpa mengubah pengalaman, dan suite itu gagal. Lebih buruk lagi, tes itu bisa terus melewati sementara perilaku yang terlihat oleh pengguna salah karena asertasi tidak pernah menjelaskan apa yang dibutuhkan pengguna untuk dilihat.

React Native Testing Library mengambil pendekatan yang berlawanan. Anda mengrender komponen, berinteraksi dengan kontrol yang terlihat, kemudian mengasertkan hasil yang dapat diamati oleh pengguna. Pendekatan itu sesuai dengan Contoh penggunaan React Native Testing Libraryseperti juga panduan pengujian React Native untuk menjaga tes singkat, fokus setiap tes pada satu hal, memisahkan kekhawatiran tampilan dari logika bisnis dan keadaan, dan memilih output yang terlihat atau bantuan aksesibilitas daripada detail implementasi internal.

Pengujian perilaku yang dipercayai oleh pengguna

Bayangkan sebuah formulir login yang mengaktifkan tombol submitnya sementara permintaan berjalan. Tes yang rapuh mungkin memeriksa disabled pada komponen instance tertentu atau mengasertkan bahwa variabel keadaan berubah. Tes yang lebih kuat menekan kontrol "Masuk" yang dapat diakses, menunggu indikator muatan, dan memeriksa bahwa pesan kesalahan atau layar tujuan muncul.

Tes kedua tidak peduli apakah formulir menggunakan state lokal, pengurang, hook khusus, atau implementasi tombol yang berbeda. Yang penting adalah aplikasi mengkomunikasikan hasil yang tepat.

Aturan praktis: Jika pengguna tidak dapat melihatnya, tanyakan apakah itu termasuk dalam tes perilaku komponen.

Kueri berdasarkan label aksesibilitas dan peran juga memaksa produk code menjadi lebih baik. Layar yang menampilkan label yang bermakna lebih mudah digunakan dengan teknologi asistif dan lebih mudah diuji. pengalaman pengguna aplikasikarena ketahanan tes dan kenyamanan pengguna sering meningkat bersamaan.

Tahu apa yang dibuktikan oleh tes yang berhasil

Tes komponen yang berpusat pada pengguna dapat membuktikan bahwa JavaScript mengrender branch yang diharapkan dan bereaksi terhadap tekanan yang disimulasikan. Namun, tidak dapat membuktikan bahwa prompt biometrik membuka dengan benar, bahwa kamera native mengembalikan hasil yang dapat digunakan, atau bahwa aliran pembayaran dapat bertahan hidup perilaku siklus platform yang spesifik.

Batasan itu bukanlah kelemahan dalam library. Itu adalah alasan untuk menjaga lapisan tes yang jujur. Gunakan RNTL untuk perilaku komponen, kemudian simpan tes perangkat untuk aliran di mana integrasi native, navigasi nyata, izin, autentikasi, pembayaran, atau fungsi aplikasi utama dapat mengubah hasil.

Pemasangan dan Konfigurasi yang Benar

Pemasangan modern dimulai dengan paket yang terikat:

@testing-library/react-native

Yang lebih tua react-native-testing-library Nama paket npm masih ada sebagai artefak sejarah, tetapi proyek-proyek saat ini harus menggunakan paket yang terstruktur dalam keluarga Testing Library. Projek’s repository GitHub menggambarkannya sebagai utilitas React Native untuk mendorong praktik-praktik tes yang baik, dan riwayat rilisnya menunjukkan bahwa library ini telah terus berubah seiring dengan React Native daripada tetap sebagai bantuan statis.

Instal library dengan lingkungan Jest yang sudah ada. Proyek Expo biasanya menggunakan preset Jest Expo, sedangkan proyek React Native yang tidak berpakaian menggunakan preset React Native:

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

Untuk Expo, tambahkan preset yang sudah digunakan proyek Anda:

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

Untuk aplikasi React Native yang tidak berpakaian, gunakan konfigurasi Jest React Native yang sesuai. Pastikan preset tetap sejalan dengan versi framework. Banyak kesalahan yang terlihat seperti masalah RNTL berasal dari kesalahan renderer React, transform Babel, atau preset Jest.

Jaga file konfigurasi eksplisit

Masukkan konfigurasi lingkungan yang dibagikan ke dalam file konfigurasi daripada mengulangi mock di setiap tes:

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

Lalu referensikan dari Jest:

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

Jika aplikasi Anda menggunakan React Navigation, Reanimated, pengolahan gestur, konteks area yang aman, atau modul penyimpanan, konfigurasi hanya mock yang dibutuhkan lingkungan tes. Mock global yang mengubah perilaku aplikasi dapat membuat setiap tes lebih mudah untuk lulus sementara membuat suite kurang dapat dipercaya.

TypeScript membutuhkan perhatian yang sama. Pastikan Jest transform .ts dan (dan) .tsx file-file melalui konfigurasi preset atau Babel Anda, dan menjaga jenis tes tersedia untuk kompiler. Sebuah tes yang berjalan lokal tetapi tidak diuji jenisnya dapat menyembunyikan nama query yang salah, parameter navigasi yang tidak valid, atau bentuk mock yang tidak aman.

Kronologi rilis ini berguna ketika mendiagnosis saran pengaturan yang lebih tua. Daftar proyek 127 rilis, dengan v14.0.1 ditandai pada 2026-06-23, sementara v12.9.0, dirilis pada 2024-11-27, menambahkan dukungan resmi untuk React Native 0.77 dan Expo 52. Garis alpha v14 pada Maret 2025 berpindah ke Universal Test Renderer dari React Test Renderer yang sudah deprecated dan mempersiapkan dukungan React 19 saja. Detail ini muncul di Riwayat Rilis RNTL, jadi jangan salin dependensi renderer dari tutorial yang sudah ketinggalan zaman tanpa memeriksa versi aplikasi Anda.

Untuk dasar Jest yang praktis, bandingkan konfigurasi Anda terhadap ini Panduan Pengujian Unit dengan JestKemudian jalankan satu tes komponen kecil sebelum menambahkan navigasi dan mock native.

API Utama, Kueri, dan Asertasi: Penjelasan

Tes RNTL menjadi dapat dipercaya ketika kueri mereka sesuai dengan apa yang pengguna dapat melihat, menemukan, dan mengoperasikan. API adalah kecil, tetapi memilih selektor yang mengungkapkan detail implementasi dapat membuat tes yang berhasil menipu.

Mulai dengan render:

const screen = render(<LoginForm />);

Pilih kueri yang paling relevan bagi pengguna. Prefer kueri yang berorientasi aksesibilitas ketika komponen mengungkapkannya, gunakan teks yang dapat dilihat ketika teks adalah perilaku, dan simpan testID untuk kasus tanpa selektor yang bermakna bagi pengguna atau di mana hook integrasi stabil diperlukan.

Pilih kueri berdasarkan waktu dan niat

Setiap keluarga kueri memiliki tujuan yang berbeda:

• Ketersediaan sinkron: Pakai getByRole, getByTextatau lainnya getBy Mengecek apakah elemen sudah ada sebelumnya. Jika tidak, tes akan gagal segera.
• Tampilan Asinkron: Pilih findByRole atau findByText ketika rendering atau interaksi menyebabkan pembaruan async.
• Pemeriksaan Kehadiran: Pilih queryByText atau queryByTestId Ketika elemen mungkin hilang dan hasil null diharapkan daripada kesalahan.
• Pemilih fallback: Pilih getByTestId Dengan sengaja. Ini memberikan kontrol kompleks sebuah hook yang tahan lama, tetapi tidak boleh menggantikan label aksesibel di seluruh aplikasi.

For tes acara yang difokuskan, fireEvent.press adalah langsung:

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

Pilih userEvent ketika versi yang terpasang mendukung urutan interaksi yang lebih realistis. Atau punya, asertikan UI hasilnya:

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

Penyataan handler cocok untuk komponen yang kontrak publiknya adalah panggilan balik acara. Ini lemah sebagai bukti satu-satunya bahwa perjalanan pengguna berfungsi.

Lebih baik gunakan penyataan spesifik daripada snapshot

Penyataan yang baik menggambarkan layar:

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

Mereka juga dapat memverifikasi status aksesibilitas, seleksi, dan umpan balik validasi yang dapat dilihat. Hindari memeriksa pengaturan internal:

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

Penyataan itu membuktikan bahwa prop ada, bukan bahwa fitur berfungsi. Snapshot kecil yang disengaja dapat menangkap perubahan struktur, sementara snapshot navigasi besar atau layar seringkali membuat ulasan yang berisik dan membuat perubahan yang tidak dijelaskan mudah disetujui.

Paket Testing Library termasuk dalam organisasi yang lebih luas testing-library Organisasi npm. Paket aktifnya mencakup @testing-library/react-nativebersama versi 13.3.3 diterbitkan pada tahun 2026, menurut informasi repositori repository informasi. Konvensi kueri yang dibagikan membantu di berbagai platform, tetapi mereka tidak menentukan asseri yang merepresentasikan perilaku produk Anda.

Untuk perbandingan yang lebih luas dari praktik pengujian komponen Jest, lihat panduan ini untuk pengujian unit React. RNTL masih berhenti di batas komponen JavaScript yang di-render. Izin-izin native, stack navigasi nyata, keyboard perangkat, waktu frame, dan perilaku memori memerlukan alat pengujian E2E atau performa daripada lebih banyak mock komponen.

Video di bawah ini menunjukkan alur kueri dan asseri dalam konteks.

Polanya Praktis untuk Komponen, Hooks, dan Navigasi

Suatu tes yang berguna mengikuti bentuk aplikasi. Komponen presentasi memerlukan tes perilaku langsung, hooks memerlukan input dan output yang dikendalikan, navigasi memerlukan penyedia yang cukup nyata, dan modul native memerlukan mock yang tetap terlihat berbeda dari verifikasi perangkat nyata.

Komponen Presentasional

Tetapkan tes komponen dekat dengan kontrak publiknya:

const onSelect = jest.fn();

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

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

expect(onSelect).toHaveBeenCalled();

Label yang tepat harus sesuai dengan UI. Bagian penting adalah bahwa tes menemukan kontrol dengan cara yang digunakan oleh pengguna atau layanan aksesibilitas dan mengkonfirmasi hasil yang terlihat atau callback yang penting. Jangan mock setiap komponen anak secara default. Mock batasan yang mahal atau tidak terkait hanya ketika mereka mengaburkan perilaku yang sedang diuji.

Untuk hook kustom, gunakan renderHook ketika versi RNTL yang terpasang menyediakannya:

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

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

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

Tes hook harus mengontrol batasan jaringan atau repositori, bukan mereproduksi aplikasi seluruhnya. Tes layar secara terpisah agar Anda tahu apakah keadaan hook menjadi UI yang berguna.

Pelayaran dan data asinkron

Pelayaran perilaku, render layar di dalam navigator yang nyata 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 Data asinkron patut memiliki disiplin yang sama. Mock atau respons repositori, render layar, asert keadaan muatan, resolusi permintaan, kemudian asert output kesuksesan atau kesalahan. Gunakan

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 Menguji permintaan yang ditolak secara eksplisit, sehingga tidak ada kesempatan untuk tes gagal karena komponen tidak mencapai cabang yang diharapkan.

Modul native palsu

Mocks untuk AsyncStorage, izin, kamera, biometrik, dan API platform berguna untuk tes JavaScript yang deterministik. Mereka tidak menunjukkan bahwa fitur native berfungsi. Simpan perilaku palsu dekat dengan kontrak modul, reset panggilan antara tes, dan termasuk respons gagal daripada mengembangkan hanya jalur bahagia.

Pembatasan adalah praktis: mock ketergantungan untuk menguji keputusan JavaScript Anda, kemudian jalankan tes perangkat untuk memastikan perilaku ketergantungan yang sebenarnya.

Debugging Test yang Rapuh CI dan Periksa Kinerja

Apa yang menyebabkan test rapuh seringkali terkait dengan waktu yang tidak terkendali, kondisi state yang bersamaan, atau asertasi yang berlari dengan UI. Identifikasi kondisi mana yang ada sebelum meningkatkan waktu tunggu. Meningkatkan waktu tunggu dapat menyembunyikan masalah jadwal dan membuat suite menjadi lebih lambat.

Pilih findBy untuk elemen yang diharapkan muncul setelah pembaruan. Pilih waitFor untuk kondisi state atau panggilan mock. Jika timer palsu diaktifkan, majukan mereka pada titik interaksi yang memerlukan dan kembalikan timer nyata setelah itu. Sebuah act Peringatan berarti React telah mengamati pembaruan di luar batas interaksi yang diharapkan. Perbaiki yang hilang await, penggunaan interaksi, atau flush timer bukan menghilangkan peringatan.

Membuat Kegagalan CI Dapat Diperulangkan

Kesalahan CI yang hanya dapat diakses perlu dibandingkan dengan lingkungan sebelum merubah komponen. Periksa Node, pengelola paket, pengaturan pekerjaan Jest, pengaturan timer, dan variabel lingkungan. Reproduksi perintah yang sama secara lokal jika memungkinkan, kemudian kurangi test yang gagal menjadi interaksi terkecil yang mengekspos perbedaan.

CI-only failures need an environment comparison before a component rewrite. Check Node, the package manager, Jest worker settings, timer configuration, and environment variables. Reproduce the same command locally where possible, then reduce the failing test to the smallest interaction that exposes the difference.

Observabilitas menutupi celah yang berbeda. Sebuah alat seperti Sentry untuk React Native memberi konteks kesalahan produksi yang tidak dapat diulang oleh tes komponen yang dibuat palsu, termasuk gagalnya yang terkait dengan perangkat asli dan integrasi 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 menguji aliran verifikasi SMS ketika integrasi tersebut membentuk bagian dari perjalanan.

Tangani kinerja sebagai pengukuran, bukan sebagai asertasi

Tes fungsional dapat memastikan bahwa daftar menampilkan. Namun, tidak dapat menentukan secara andal apakah refactor mengubah durasi render atau jumlah render, karena waktu eksekusi tes menambahkan kebisingan. Pastikan nilai-nilai tersebut untuk skenario, ulangi skenario untuk mengurangi varian, dan aplikasikan analisis statistik sebelum melaporkan perubahan yang berarti. Dokumentasi Dokumentasi Pengujian Kinerja juga mencakup laporan yang sesuai untuk CI dan tinjauan pull-request.

Hindari asertasi tetap seperti "render ini harus selesai di bawah ambang batas yang dipilih." Pekerja CI yang sibuk dapat menyebabkan gagal palsu, sementara ambang batas yang longgar dapat melewatkan regresi yang sebenarnya. Gunakan pengukuran yang diulang untuk sinyal regresi, kemudian periksa komponen dan profil perangkat ketika perbandingan menunjukkan perbedaan yang berarti.

Aturan pengukuran: Tes fungsional menjawab apakah perilaku benar. Alat pengukuran menjawab apakah skenario yang diukur berubah. Jaga pertanyaan-pertanyaan tersebut terpisah.

Menyatukan Semua dan Bergerak Maju

React Native Testing Library masuk dalam lapisan cepat, luas dari strategi tes Anda. Ini harus menutup perilaku komponen, perubahan keadaan yang dapat dilihat, hasil aksesibilitas, validasi, keadaan data yang dibuat palsu, dan integrasi antara komponen JavaScript. Tetapkan tes-tes tersebut fokus pada apa yang dapat diamati oleh pengguna, dan buat kegagalan menunjuk pada perilaku tertentu daripada pohon yang di-render besar.

Lapisan perangkat yang lebih kecil harus melindungi arus di mana mock dapat bersembunyi. React Native's Ringkasan Pengujian states that RNTL doesn’t provide a full React Native runtime and can’t test native features. The same guidance recommends pairing component tests with E2E tools such as Detox for critical flows including authentication, payments, and core app functionality.

Rute migrasi yang praktis

Anda tidak perlu menulis ulang suatu suite yang sudah ada dalam satu kali.

1. Terjaga tes bisnis yang berharga. Pindahkan keadaan murni dan logika domain ke tes unit yang fokus, di mana mereka memberikan feedback yang jelas.
2. Ganti asertasi implementasi terlebih dahulu. Ubah pengecekan properti dan keadaan internal menjadi hasil output yang dapat dilihat, keadaan aksesibilitas, dan hasil interaksi.
3. Mengurangi pratinjau skrin. Jangan perlu menulis ulang suatu suite yang sudah ada dalam satu kali.
4. Tambahkan coverage batasan native. Untuk setiap modul penting yang di mock, identifikasi perilaku perangkat yang masih perlu divalidasi.
5. Lindungi perjalanan kritis. Tambahkan coverage E2E untuk autentikasi, pembayaran, navigasi utama, izin, dan alur lainnya di mana perilaku native dapat mengubah hasil.
6. Ukurlah layar sensitif secara terpisah. Gunakan perbandingan kinerja yang diulang untuk daftar, feed, dan jalur render yang mahal daripada menebak dari durasi Jest.

Untuk kepercayaan rilis, hubungkan suite ke integrasi testing CI/CD dan memerlukan layer test yang tepat sebelum mengirim. Jika perbaikan JavaScript atau asset harus mencapai pengguna setelah validasi, Capgo dapat mengirimkan bundle web yang ditandatangani ke saluran yang ditargetkan untuk aplikasi CapacitorJS dan Electron, dengan kontrol rollout dan proteksi rollback. Alur pengiriman tersebut tidak menggantikan tes perangkat React Native, tetapi mengilustrasikan prinsip yang sama: divalidasi perilaku di lapisan di mana itu berjalan.

Pertanyaan yang tepat bukanlah apakah React Native Testing Library dapat mengetes aplikasi Anda secara keseluruhan. Ia tidak bisa, dan batasan resmi berguna. Pertanyaan yang tepat adalah apakah setiap risiko penting memiliki tes yang berjalan di lingkungan yang dapat mengeksposnya.

Capgo menghubungkan perubahan JavaScript dan asset yang divalidasi ke pengiriman yang dikendalikan untuk tim CapacitorJS dan Electron, dengan saluran yang ditargetkan, visibilitas rollout, dan proteksi rollback. Kunjungi Capgo Untuk melihat bagaimana cara mengintegrasikannya dengan alur kerja testing E2E, dan CI Anda.