Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Hal yang harus Anda uji bergantung pada beberapa faktor seperti jenis aplikasi, tim
pengembangan, jumlah kode lama, dan arsitektur yang digunakan. Bagian berikut
menjelaskan hal-hal yang mungkin perlu dipertimbangkan pemula saat merencanakan
hal yang akan diuji di aplikasi mereka.
Organisasi direktori pengujian
Project standar di Android Studio berisi dua direktori yang menyimpan pengujian,
bergantung pada lingkungan eksekusinya. Atur pengujian Anda dalam direktori
berikut seperti yang dijelaskan:
Direktori androidTest harus berisi pengujian yang berjalan di perangkat nyata atau
virtual. Pengujian tersebut mencakup pengujian integrasi, pengujian menyeluruh, dan
pengujian lain dengan JVM saja tidak dapat memvalidasi fungsionalitas aplikasi.
Direktori test harus berisi pengujian yang dijalankan di mesin lokal Anda,
seperti pengujian unit. Berbeda dengan yang di atas, ini dapat berupa pengujian yang dijalankan di
JVM lokal.
Pengujian unit yang penting
Saat mengikuti praktik terbaik, Anda harus memastikan bahwa Anda menggunakan pengujian unit dalam
kasus berikut:
Pengujian unit untuk ViewModels, atau presenter.
Pengujian unit untuk lapisan data, terutama repositori. Sebagian besar
lapisan data harus tidak bergantung pada platform. Dengan melakukannya, pengujian ganda akan dapat
menggantikan modul database dan sumber data jarak jauh dalam pengujian. Lihat panduan tentang
menggunakan dummy pengujian di Android
Pengujian unit untuk lapisan lain yang tidak bergantung pada platform seperti lapisan Domain, seperti pada kasus penggunaan dan pemicu interaksi.
Pengujian unit untuk class utilitas seperti manipulasi string dan matematika.
Menguji Kasus Edge
Pengujian unit harus berfokus pada kasus normal dan kasus ekstrem. Kasus ekstrem adalah skenario yang jarang terjadi dan sulit ditemukan oleh penguji manusia dan pengujian yang lebih besar. Contohnya
antara lain:
Operasi matematika menggunakan bilangan negatif, nol, dan kondisi
batas.
Semua kemungkinan error koneksi jaringan.
Data yang rusak, seperti format JSON yang salah.
Menyimulasikan penyimpanan penuh saat menyimpan ke file.
Objek dibuat ulang di tengah proses (seperti aktivitas saat
perangkat diputar).
Pengujian Unit yang Harus Dihindari
Beberapa pengujian unit harus dihindari karena nilainya rendah:
Pengujian yang memverifikasi operasi framework atau library yang benar, bukan
kode Anda.
Titik entri framework seperti aktivitas, fragmen, atau layanan tidak boleh
memiliki logika bisnis sehingga pengujian unit tidak boleh menjadi prioritas. Pengujian unit untuk
aktivitas memiliki sedikit nilai, karena pengujian tersebut akan mencakup sebagian besar kode framework
dan memerlukan penyiapan yang lebih rumit. Pengujian berinstrumen seperti pengujian UI
dapat mencakup class ini.
Pengujian UI
Ada beberapa jenis pengujian UI yang harus Anda gunakan:
Pengujian UI Layar memeriksa interaksi pengguna yang penting dalam satu layar. Fungsi ini
melakukan tindakan seperti mengklik tombol, mengetik formulir, dan memeriksa status
yang terlihat. Satu class pengujian per layar merupakan titik awal yang baik.
Pengujian alur pengguna atau Pengujian navigasi, yang mencakup jalur paling umum. Pengujian
ini menyimulasikan pengguna yang bergerak melalui alur navigasi. Pengujian ini adalah pengujian sederhana, yang berguna untuk memeriksa error pada runtime dalam inisialisasi.
Pengujian lainnya
Ada pengujian yang lebih khusus seperti pengujian screenshot, pengujian performa,
dan pengujian monyet. Anda juga dapat mengategorikan pengujian berdasarkan tujuan, seperti
regresi, aksesibilitas, dan kompatibilitas.
Bacaan lebih lanjut
Untuk menguji secara terpisah, sering kali Anda harus mengganti dependensi
subjek yang sedang diuji dengan dependensi palsu atau tiruan, yang disebut "Kembaran pengujian"
secara umum. Lanjutkan membaca tentang hal tersebut di Menggunakan dummy pengujian di Android.
Jika Anda ingin mempelajari cara membuat pengujian unit dan UI, lihat codelab
Pengujian.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-27 UTC."],[],[],null,["# What to test in Android\n\nWhat you should test depends on factors such as the type of app, the development\nteam, the amount of legacy code, and the architecture used. The following\nsections outline what a beginner might want to consider when planning what to\ntest in their app.\n\nOrganization of test directories\n--------------------------------\n\nA typical project in Android Studio contains two directories that hold tests\ndepending on their execution environment. Organize your tests in the following\ndirectories as described:\n\n- The `androidTest` directory should contain the tests that run on real or virtual devices. Such tests include integration tests, end-to-end tests, and other tests where the JVM alone cannot validate your app's functionality.\n- The `test`directory should contain the tests that run on your local machine, such as unit tests. In contrast to the above, these can be tests that run on a local JVM.\n\nEssential unit tests\n--------------------\n\nWhen following best practice, you should ensure you use unit tests in the\nfollowing cases:\n\n- **Unit tests** for **ViewModels**, or presenters.\n- **Unit tests** for the **data** layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests. See the guide on [using test doubles in Android](/training/testing/fundamentals/test-doubles)\n- **Unit tests** for other platform-independent layers such as the **Domain** layer, as with use cases and interactors.\n- **Unit tests** for **utility classes** such as string manipulation and math.\n\n### Testing Edge Cases\n\nUnit tests should focus on both normal and edge cases. Edge cases are uncommon\nscenarios that human testers and larger tests are unlikely to catch. Examples\ninclude the following:\n\n- Math operations using negative numbers, zero, and [boundary\n conditions](https://en.wikipedia.org/wiki/Off-by-one_error).\n- All the possible network connection errors.\n- Corrupted data, such as malformed JSON.\n- Simulating full storage when saving to a file.\n- Object recreated in the middle of a process (such as an activity when the device is rotated).\n\n### Unit Tests to Avoid\n\nSome unit tests should be avoided because of their low value:\n\n- Tests that verify the correct operation of the framework or a library, not your code.\n- Framework entry points such as *activities, fragments, or services* should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes.\n\nUI tests\n--------\n\nThere are several types of UI tests you should employ:\n\n- **Screen UI tests** check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point.\n- **User flow tests** or **Navigation tests**, covering most common paths. These tests simulate a user moving through a navigation flow. They are simple tests, useful for checking for run-time crashes in initialization.\n\n| **Note:** Test coverage is a metric that some testing tools can calculate, and indicates how much of your code is visited by your tests. It can detect untested portions of the codebase, but it should not be used as the only metric to claim a good testing strategy.\n\nOther tests\n-----------\n\nThere are more specialized tests such as screenshot tests, performance tests,\nand [monkey tests](/studio/test/monkey). You can also categorize tests by purpose, such as\nregressions, accessibility, and compatibility.\n\nFurther reading\n---------------\n\nIn order to test in isolation, you oftentimes need to replace the dependencies\nof the subject under test with fake or mock dependencies, called \"Test doubles\"\nin general. Continue reading about them in [Using test doubles in Android](/training/testing/fundamentals/test-doubles).\n\nIf you want to learn how to create unit and UI tests, check out the [Testing\ncodelabs](/codelabs/advanced-android-kotlin-training-testing-basics)."]]
