Cara Menguji Aplikasi dengan React Native Testing Library

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

Itu adalah celah di mana tim mendapatkan kepercayaan palsu. React Native Testing Library adalah sangat baik untuk menguji apa yang komponen tersebut menampilkan dan bagaimana komponen tersebut bereaksi terhadap interaksi pengguna, tetapi tidak dapat menggantikan pengujian perangkat atau pengukuran kinerja. Strategi yang dapat diandalkan adalah menggunakan setiap lapisan untuk kegagalan yang dapat terpapar.

Daftar Isi

• Kenapa Pengujian Berpusat pada Pengguna Mengubah Semua
  • Uji perilaku yang dipercayai pengguna
  • Tahu apa yang tidak dibuktikan oleh tes yang berhasil
• Penginstalan dan Konfigurasi yang Benar-Benar Berfungsi
  • Jaga file pengaturan eksplisit
• API Utama, Kueri, dan Asertasi yang Dijelaskan
  • Pilih kueri berdasarkan waktu dan niat
  • Lebih baik menggunakan asertasi spesifik daripada tangkapan layar
• Polanya yang Praktis untuk Komponen, Hook, dan Navigasi
  • Komponen Presentasional
  • Navigation dan Data Asinkron
  • Mudah-mudahan Modul Nativ
• Debugging Uji Coba yang Rentan, Pengujian CI, dan Pengujian Kinerja
  • Ubah Uji Coba CI agar Dapat Diperbaiki
  • Tangani Kinerja sebagai Pengukuran, Bukan Pengakuan
• Menggabungkan Semua dan Melangkah Maju
  • Jalan Migrasi yang Praktis

Mengapa Pengujian yang Berpusat pada Pengguna Mengubah Semua

Uji Coba yang Paling Umum gagal sebelum uji coba itu ditulis. Seorang pengembang memeriksa prop komponen, mencapai ke dalam keadaan komponen, atau membandingkan snapshot besar karena detail-detail itu mudah untuk diakui. Uji coba berhasil, kemudian refactor mengubah struktur komponen tanpa mengubah pengalaman, dan suite gagal. Lebih buruk lagi, uji coba dapat terus berhasil sementara perilaku yang dapat dilihat pengguna salah karena pengakuan tidak pernah menjelaskan apa yang dibutuhkan pengguna.

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

Tes perilaku yang digunakan

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

Tes kedua tidak peduli apakah formulir menggunakan keadaan lokal, pengurang, hook kustom, atau implementasi tombol yang berbeda. Dia peduli bahwa aplikasi menyampaikan hasil yang tepat.

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

Kueri yang 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. Koneksi itu penting ketika Anda menilai pengalaman pengguna aplikasi yang lebih luas. karena ketahanan tes dan kenyamanan pengguna sering meningkat bersamaan.Tahu apa yang tidak dibuktikan oleh tes yang berhasil

Tes yang berhasil tidak membuktikan bahwa aplikasi tidak akan gagal atau tidak akan mengalami masalah.

A tes component yang berfokus pada pengguna dapat membuktikan bahwa JavaScript menampilkan cabang 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 bertahan hidup terhadap perilaku siklus platform yang spesifik.

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

Pemasangan dan Konfigurasi yang Benar-Benar Berfungsi

Pemasangan modern dimulai dengan paket yang terikat:

@testing-library/react-native

Paket lama masih ada sebagai artefak sejarah, tetapi proyek-proyek saat ini harus menggunakan paket yang terikat dan dipelihara dalam keluarga Testing Library. Repositori proyek react-native-testing-library npm package name still exists as a historical artifact, but current projects should use the scoped package maintained within the Testing Library family. The project’s GitHub repository Untuk Expo, tambahkan preset yang sudah digunakan proyek Anda:

__CAPGO_KEEP_0__

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

__CAPGO_KEEP_0__

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

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

Jaga file pengaturan menjadi eksplisit

Masukkan konfigurasi lingkungan yang dibagikan ke dalam file pengaturan 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, pengelolaan gestur, konteks area yang aman, atau modul penyimpanan, konfigurasi hanya mock yang dibutuhkan oleh lingkungan tes. Mock global yang mengubah perilaku aplikasi dapat membuat setiap tes lebih mudah untuk lulus, tetapi membuat suite kurang dapat dipercaya.

TypeScript memerlukan perhatian yang sama. Pastikan Jest mengubah .ts dan .tsx context

file melalui preset atau konfigurasi Babel Anda, dan pastikan jenis tes tersedia untuk kompiler. Tes yang berjalan lokal tetapi tidak dievaluasi jenisnya dapat menyembunyikan nama query yang salah, parameter navigasi yang tidak valid, atau bentuk mock yang tidak aman. Kronologi rilis berguna ketika mendiagnosis saran pengaturan yang lebih tua. Proyek ini memiliki127 rilis , dengan versi v14.0.1 yang ditandai pada 2026-06-23sedangkan 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 beralih ke Universal Test Renderer dari React Test Renderer yang sudah usang dan mempersiapkan dukungan React 19 saja. Rincian ini muncul diRilis Sejarah RNTL

, jadi jangan salin dependensi renderer dari tutorial yang sudah usang tanpa memeriksa versi aplikasi Anda. Untuk dasar Jest yang praktis, bandingkan konfigurasi Anda denganPanduan Unit Testing Jest

Infografis menunjukkan jalur instalasi lima langkah untuk mengatur proyek 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.

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

const screen = render(<LoginForm />);

Pilihlah kueri yang paling relevan bagi pengguna. Prefer kueri yang berorientasi aksesibilitas ketika komponen menampilkan mereka, gunakan teks yang dapat dilihat ketika teks adalah perilaku, dan simpan testID Pilihlah kueri berdasarkan waktu dan niat

Pilihlah kueri berdasarkan waktu dan niat

Setiap keluarga kueri memiliki tujuan yang unik:

• Kehadiran sinkron: Pilihlah kueri getByRole, getByTextatau kueri lainnya ketika elemen harus sudah ada. Jika tidak, tes akan gagal segera. getBy Penampilan asinkron:
• Pilihlah kueri atau kueri lainnya ketika elemen harus sudah ada. Jika tidak, tes akan gagal segera. findByRole Pilihlah kueri berdasarkan waktu dan niat findByText ketika rendering atau interaksi menyebabkan pembaruan async.
• Absensi cek: Pilih queryByText atau queryByTestId Gunakan
• atau Gunakan getByTestId untuk memastikan kontrol kompleks memiliki hook yang tahan lama, tetapi jangan menggantikan label aksesibel di seluruh aplikasi.

Untuk tes event 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. Dengan cara apa pun, asertikan UI hasilnya:

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

Aduan handler sesuai dengan komponen yang memiliki kontrak publik sebagai panggilan balik acara. Ini lemah karena bukti yang lemah bahwa perjalanan pengguna berfungsi.

Lebih baik menggunakan aduan spesifik daripada tangkapan layar

Penjelasan aduan 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 terlihat. Hindari memeriksa pengaturan internal:

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

Aduan ini membuktikan bahwa prop ada, bukan bahwa fitur berfungsi. Tangkapan layar kecil dan sengaja dapat menangkap perubahan struktur, sementara tangkapan layar navigasi besar atau layar seringkali menciptakan ulasan berisik dan membuat perubahan tidak terduga mudah disetujui.

Paket Testing Library termasuk dalam organisasi yang lebih luas testing-library npm @testing-library/react-nativeVersi 13.3.3 diterbitkan pada tahun 2026 menurut informasi repository proyek. Konvensi kueri yang dibagikan membantu di antara platform, tetapi tidak menentukan aduan mana yang merepresentasikan perilaku produk Anda. Preferensi aduan spesifik lebih baik daripada tangkapan layarAduan yang baik menggambarkan layar: mereka juga dapat memverifikasi status aksesibilitas, seleksi, dan umpan balik validasi yang terlihat. Hindari memeriksa pengaturan internal: itu membuktikan bahwa prop ada, bukan bahwa fitur berfungsi. Tangkapan layar kecil dan sengaja dapat menangkap perubahan struktur, sementara tangkapan layar navigasi besar atau layar seringkali menciptakan ulasan berisik dan membuat perubahan tidak terduga mudah disetujui.

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

The video di bawah menunjukkan alur query dan asertasi dalam konteks.

Polanya Praktis untuk Komponen, Hooks, dan Navigasi

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

Komponen presentasional

Tetapkan tes komponen dekat dengan kontrak publik:

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 seperti cara pengguna atau layanan aksesibilitas dan mengkonfirmasi hasil yang terlihat atau callback yang penting. Jangan mock setiap komponen anak secara default. Mock batas yang mahal atau tidak terkait hanya ketika mereka mengaburkan perilaku yang diuji.

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

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

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

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

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

Navigation dan data asinkron

Untuk perilaku navigasi, menampilkan layar di dalam sebuah real NavigationContainer dan navigator uji kecil seringkali lebih berharga daripada menggantikan setiap metode navigasi. Tekan sebuah kontrol yang terlihat, tunggu konten tujuan, dan asertikan output layar baru. Mock langsung masih sesuai untuk sebuah tombol kecil yang hanya bertanggung jawab mengirimkan sebuah rute yang ditipekan, tetapi tidak akan memvalidasi pendaftaran rute, parameter, atau perilaku navigator yang terikat. useNavigation Data asinkron patut mendapatkan disiplin yang sama. Mock __CAPGO_KEEP_0__ atau respons repositori, render layar, asertikan keadaan muat, resolusi permintaan, kemudian asertikan 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 Mock modul native

Mock untuk AsyncStorage, izin, kamera, biometrik, dan API platform berguna untuk uji JavaScript yang deterministik. Mereka tidak menjadi bukti bahwa fitur native berfungsi. Simpan perilaku mock dekat dengan kontrak modul, reset panggilan antara uji, dan termasuk respons gagal daripada hanya meniru jalur bahagia.

Skenario

Pemisahan batasnya praktis: mock ketergantungan untuk menguji keputusan JavaScript Anda, kemudian jalankan tes perangkat untuk memastikan perilaku ketergantungan nyata.

Pengujian yang Rentan, Pengujian CI, dan Pengujian Kinerja

Tes yang rentan sering menunjukkan waktu yang tidak terkendali, kondisi bersama, atau asertasi yang bersaing dengan UI. Identifikasi kondisi mana yang ada sebelum meningkatkan waktu tunggu. Waktu tunggu yang lebih lama dapat menyembunyikan masalah jadwal dan membuat suite lebih lambat.

Pakai findBy untuk elemen yang diharapkan muncul setelah pembaruan. Pakai waitFor untuk kondisi keadaan atau panggilan mock. Jika timer palsu diaktifkan, majukan mereka pada titik interaksi yang memerlukan dan kembalikan timer nyata setelahnya. Sebuah act Pesan peringatan berarti React telah mengamati pembaruan di luar batas interaksi yang diharapkan. Perbaiki yang hilang awaitatau penggunaan interaksi, atau flush timer daripada menindaklanjuti pesan peringatan.

Pastikan gagalnya CI dapat direproduksi

Job CI yang dapat dipercaya menginstal dari file lock, menjalankan perintah Jest yang sama digunakan secara lokal, dan mengisolasi status mock. Hapus panggilan mock antara tes, reset modul ketika status modul berpengaruh terhadap perilaku, dan hapus ketergantungan pada urutan eksekusi. Penggunaan cache Jest mempercepat feedback, tetapi perubahan dependensi atau konfigurasi memerlukan penghapusan cache yang tepat.

Gagal CI yang hanya dapat diakses perlu dibandingkan dengan lingkungan sebelum melakukan perubahan komponen. Periksa Node, pengelola paket, pengaturan pekerjaan Jest, pengaturan timer, dan variabel lingkungan. Reproduksi perintah yang sama secara lokal di mana mungkin, kemudian reduksi tes yang gagal ke interaksi terkecil yang mengekspos perbedaan.

Observabilitas menutupi celah yang berbeda. Alat seperti Sentry untuk React Native menyediakan konteks kesalahan produksi yang tidak dapat direproduksi oleh tes komponen yang dibuat palsu, termasuk gagal 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 merupakan bagian dari perjalanan.

Tangani kinerja sebagai pengukuran, bukan sebagai asertasi

A tes fungsi dapat memastikan bahwa sebuah daftar ditampilkan. Namun, tidak dapat secara andal menentukan apakah perubahan refactor mengubah durasi render atau jumlah render, karena waktu eksekusi tes menambahkan kebisingan. Pengukuran ini mengukur nilai-nilai tersebut untuk sebuah skenario, mengulangi skenario untuk mengurangi varian, dan menerapkan analisis statistik sebelum melaporkan perubahan yang berarti. Dokumentasi pengujian kinerja juga mencakup laporan yang sesuai untuk CI dan tinjauan pull-request. Hindari asertasi yang tetap seperti “render ini harus selesai di bawah ambang batas yang dipilih.” Pekerja CI yang sibuk dapat menyebabkan kegagalan palsu, sementara ambang batas yang longgar dapat melewatkan regresi yang sebenarnya. Gunakan pengukuran yang diulang untuk signal regresi, kemudian periksa komponen dan profil perangkat ketika perbandingan menunjukkan perbedaan yang berarti.

Aturan pengukuran:

Pengujian fungsi menjawab apakah perilaku benar. Alat pengujian kinerja menjawab apakah skenario yang diukur berubah. Jaga kedua pertanyaan tersebut terpisah. Menyatukan Semua dan Membangun Langkah Selanjutnya

Pustaka Pengujian React Native termasuk dalam lapisan cepat dan luas dari strategi tes Anda. Ini harus mencakup perilaku komponen, perubahan keadaan yang dapat dilihat, hasil aksesibilitas, validasi, keadaan data yang dibuat palsu, dan integrasi antara komponen JavaScript. Jaga tes tersebut fokus pada apa yang dapat diamati oleh pengguna, dan buat kegagalan menunjuk pada perilaku tertentu daripada pohon yang ditampilkan besar.

Lapisan perangkat yang lebih kecil harus melindungi aliran-aliran di mana palsu dapat bersembunyi. Pengujian React Native

Ringkasan pengujian React Native Pengujian React Native termasuk dalam lapisan cepat dan luas dari strategi tes Anda. Ini harus mencakup perilaku komponen, perubahan keadaan yang dapat dilihat, hasil aksesibilitas, validasi, keadaan data yang dibuat palsu, dan integrasi antara komponen JavaScript. Jaga tes tersebut fokus pada apa yang dapat diamati oleh pengguna, dan buat kegagalan menunjuk pada perilaku tertentu daripada pohon yang ditampilkan besar. menyatakan bahwa RNTL tidak menyediakan runtime React Native penuh dan tidak dapat menguji fitur native. Petunjuk yang sama merekomendasikan menggabungkan tes komponen dengan alat E2E seperti Detox untuk aliran kritikal termasuk autentikasi, pembayaran, dan fungsi aplikasi utama.

Jalur migrasi yang praktis

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

1. Tahan tes bisnis yang berharga. Pindahkan logika negara dan logika domain ke tes unit yang fokus di mana mereka memberikan feedback yang jelas.
2. Ganti asertasi implementasi terlebih dahulu. Ubah pengecekan atribut dan keadaan internal menjadi hasil keluaran yang dapat dilihat, keadaan aksesibilitas, dan hasil interaksi.
3. Kurangi snapshot. Tahan hanya snapshot yang dapat dipahami dan dipelihara oleh reviewer.
4. Tambahkan penutupan batas native. Untuk setiap modul yang dimock yang penting, identifikasi perilaku perangkat yang masih perlu validasi.
5. Lindungi perjalanan kritikal. Menambahkan penutupan akhir ke akurasi untuk autentikasi, pembayaran, navigasi inti, izin, dan aliran lainnya di mana perilaku asli dapat mengubah hasil.
6. Measuring layar sensitif secara terpisah. Menggunakan perbandingan kinerja yang diulang untuk daftar, feed, dan jalur render yang mahal bukan dengan 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 perlindungan rollback. Alur pengiriman tersebut tidak menggantikan tes perangkat React Native, tetapi mengilustrasikan prinsip yang sama: memvalidasi perilaku di lapisan di mana perilaku tersebut berjalan.

Kata 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 diverifikasi ke pengiriman yang dikendalikan untuk tim CapacitorJS dan Electron, dengan saluran yang ditargetkan, visibilitas rollout, dan perlindungan rollback. Kunjungi Capgo context