Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Menarget contoh aplikasi

Kategori pengujian instrumentasi ini tidak jauh berbeda dengan pengujian yang menargetkan aplikasi Android biasa. Perlu diperhatikan bahwa aplikasi pengujian yang menyertakan instrumentasi harus ditandatangani dengan sertifikat yang sama dengan aplikasi yang ditargetkan.

Perhatikan bahwa panduan ini mengasumsikan bahwa Anda sudah memiliki pengetahuan tentang alur kerja hierarki sumber platform. Jika tidak, lihat Persyaratan. Contoh yang dibahas di sini adalah menulis pengujian instrumentasi baru dengan paket target yang ditetapkan di paket aplikasi pengujiannya sendiri. Jika Anda belum memahami konsepnya, baca Pengantar pengujian platform.

Panduan ini menggunakan uji berikut sebagai contoh:

frameworks/base/packages/Shell/tests

Sebaiknya jelajahi kode terlebih dahulu untuk mendapatkan gambaran kasar sebelum melanjutkan.

Tentukan lokasi sumber

Karena pengujian instrumentasi akan menargetkan aplikasi, konvensinya adalah menempatkan kode sumber pengujian di direktori tests di bawah root direktori sumber komponen di hierarki sumber platform.

Lihat diskusi selengkapnya tentang lokasi sumber dalam contoh end-to-end untuk pengujian berinstrumen sendiri.

File manifes

Sama seperti aplikasi biasa, setiap modul pengujian instrumentasi memerlukan file manifes. Jika Anda memberi nama file sebagai AndroidManifest.xml dan menyediakannya di samping Android.mk untuk modul pengujian, file tersebut akan otomatis disertakan oleh file make inti BUILD_PACKAGE.

Sebelum melanjutkan, sebaiknya Anda membaca Ringkasan Manifes Aplikasi terlebih dahulu.

Bagian ini memberikan ringkasan komponen dasar file manifes dan fungsinya.

Versi terbaru file manifes untuk perubahan gerrit sampel dapat diakses di: https://android.googlesource.com/platform/frameworks/base/+/android16-release/packages/Shell/tests/AndroidManifest.xml

Snapshot disertakan di sini untuk memudahkan:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>

Beberapa catatan penting tentang file manifes:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

Atribut package adalah nama paket aplikasi: ini adalah ID unik yang digunakan framework aplikasi Android untuk mengidentifikasi aplikasi (atau dalam konteks ini: aplikasi pengujian Anda). Setiap pengguna dalam sistem hanya dapat menginstal satu aplikasi dengan nama paket tersebut.

Karena ini adalah paket aplikasi pengujian, yang terpisah dari paket aplikasi yang sedang diuji, nama paket yang berbeda harus digunakan: salah satu konvensi umum adalah menambahkan akhiran .test.

Selain itu, atribut package ini sama dengan yang ditampilkan ComponentName#getPackageName(), dan juga sama dengan yang akan Anda gunakan untuk berinteraksi dengan berbagai subperintah pm melalui adb shell.

Perhatikan juga bahwa meskipun nama paket biasanya memiliki gaya yang sama dengan nama paket Java, sebenarnya nama paket memiliki sangat sedikit kesamaan dengan nama paket Java. Dengan kata lain, paket aplikasi (atau pengujian) Anda dapat berisi class dengan nama paket apa pun, meskipun di sisi lain, Anda dapat memilih kesederhanaan dan memiliki nama paket Java tingkat atas di aplikasi atau pengujian yang identik dengan nama paket aplikasi.

<uses-library android:name="android.test.runner" />

Hal ini diperlukan untuk semua pengujian Instrumentation karena class terkait dikemas dalam file library jar framework terpisah, sehingga memerlukan entri classpath tambahan saat paket pengujian dipanggil oleh framework aplikasi.

android:targetPackage="com.android.shell"

Tindakan ini akan menetapkan paket target instrumentasi ke com.android.shell. Saat instrumentasi dipanggil melalui perintah am instrument, framework akan memulai ulang proses com.android.shell, dan menyuntikkan kode instrumentasi ke dalam proses untuk eksekusi pengujian. Artinya juga, kode pengujian akan memiliki akses ke semua instance class yang berjalan di aplikasi yang sedang diuji dan mungkin dapat memanipulasi status bergantung pada hook pengujian yang diekspos.

File konfigurasi sederhana

Setiap modul pengujian baru harus memiliki file konfigurasi untuk mengarahkan sistem build dengan metadata modul, dependensi waktu kompilasi, dan petunjuk pengemasan. Dalam sebagian besar kasus, opsi file Blueprint berbasis Soong sudah cukup. Lihat Konfigurasi Pengujian Sederhana untuk mengetahui detailnya.

File konfigurasi yang kompleks

Untuk pengujian yang lebih kompleks, Anda juga perlu menulis file konfigurasi pengujian untuk platform pengujian Android, Trade Federation.

Konfigurasi pengujian dapat menentukan opsi penyiapan perangkat khusus dan argumen default untuk menyediakan class pengujian.

Versi terbaru file konfigurasi untuk perubahan gerrit contoh dapat diakses di: frameworks/base/packages/Shell/tests/AndroidTest.xml

Snapshot disertakan di sini untuk memudahkan:

<configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>

Beberapa catatan pilihan pada file konfigurasi pengujian:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>

Perintah ini memberi tahu Trade Federation untuk menginstal ShellTests.apk ke perangkat target menggunakan target_preparer yang ditentukan. Ada banyak penyiap target yang tersedia untuk developer di Trade Federation dan dapat digunakan untuk memastikan perangkat disiapkan dengan benar sebelum eksekusi pengujian.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

Ini menentukan class pengujian Trade Federation yang akan digunakan untuk mengeksekusi pengujian dan meneruskan paket di perangkat yang akan dieksekusi dan framework runner pengujian yang dalam hal ini adalah JUnit.

Lihat di sini untuk mengetahui informasi selengkapnya tentang Konfigurasi Modul Pengujian

Fitur JUnit4

Menggunakan library android-support-test sebagai pelaksana pengujian memungkinkan adopsi class pengujian gaya JUnit4 baru, dan contoh perubahan gerrit berisi beberapa penggunaan yang sangat mendasar dari fiturnya.

Kode sumber terbaru untuk perubahan gerrit contoh dapat diakses di: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Meskipun pola pengujian biasanya khusus untuk tim komponen, ada beberapa pola penggunaan yang umumnya berguna.

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

Perbedaan signifikan dalam JUnit4 adalah pengujian tidak lagi harus diwarisi dari class pengujian dasar umum; sebagai gantinya, Anda menulis pengujian di class Java biasa dan menggunakan anotasi untuk menunjukkan penyiapan dan batasan pengujian tertentu. Dalam contoh ini, kita menginstruksikan agar class ini dijalankan sebagai pengujian Android JUnit4.

Anotasi @SmallTest menentukan ukuran pengujian untuk seluruh class pengujian: semua metode pengujian yang ditambahkan ke class pengujian ini mewarisi anotasi ukuran pengujian ini. Penyiapan class pra-pengujian, penonaktifan pasca-pengujian, dan penonaktifan class pasca-pengujian: mirip dengan metode setUp dan tearDown di JUnit4. Anotasi Test digunakan untuk memberikan anotasi pada pengujian sebenarnya.

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

Anotasi @Before digunakan pada metode oleh JUnit4 untuk melakukan penyiapan pra-pengujian. Meskipun tidak digunakan dalam contoh ini, ada juga @After untuk peniadaan setelah pengujian. Demikian pula, anotasi @BeforeClass dan @AfterClass dapat digunakan pada metode oleh JUnit4 untuk melakukan penyiapan sebelum mengeksekusi semua pengujian dalam class pengujian, dan penguraian setelahnya. Perhatikan bahwa metode penyiapan dan penghentian cakupan class harus statis.

Untuk metode pengujian, tidak seperti pada versi JUnit sebelumnya, metode tersebut tidak perlu lagi memulai nama metode dengan test, melainkan setiap metode harus dianotasi dengan @Test. Seperti biasa, metode pengujian harus bersifat publik, tidak mendeklarasikan nilai yang ditampilkan, tidak menggunakan parameter, dan dapat menampilkan pengecualian.

        Context context = InstrumentationRegistry.getTargetContext();

Karena pengujian JUnit4 tidak lagi memerlukan class dasar umum, Context tidak lagi perlu diperoleh melalui getContext() atau getTargetContext() melalui metode class dasar; sebagai gantinya, peluncur pengujian baru mengelolanya melalui InstrumentationRegistry tempat penyiapan kontekstual dan lingkungan yang dibuat oleh framework instrumentasi disimpan. Melalui class ini, Anda juga dapat memanggil:

getInstrumentation(): instance ke class Instrumentation
getArguments(): argumen command line yang diteruskan ke am instrument melalui -e <key> <value>

Membuat dan menguji secara lokal

Untuk kasus penggunaan yang paling umum, gunakan Atest.

Untuk kasus yang lebih kompleks yang memerlukan penyesuaian lebih berat, ikuti petunjuk instrumentasi.