Targetkan 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 pohon sumber platform. Jika tidak, silakan lihat Persyaratan . Contoh yang dibahas di sini adalah menulis pengujian instrumentasi baru dengan paket target yang ditetapkan pada paket aplikasi pengujiannya sendiri. Jika Anda belum terbiasa dengan konsep ini, silakan baca pengenalan pengujian Platform .

Panduan ini menggunakan tes berikut sebagai sampel:

  • frameworks/base/packages/Shell/tests

Disarankan untuk menelusuri kode terlebih dahulu untuk mendapatkan gambaran kasar sebelum melanjutkan.

Tentukan lokasi sumber

Karena pengujian instrumentasi akan menargetkan aplikasi, ketentuannya adalah menempatkan kode sumber pengujian di direktori tests di bawah akar direktori sumber komponen Anda di pohon sumber platform.

Lihat diskusi selengkapnya tentang lokasi sumber dalam contoh end-to-end untuk pengujian instrumentasi mandiri .

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 tmodule pengujian Anda, file tersebut akan disertakan secara otomatis oleh makefile inti BUILD_PACKAGE .

Sebelum melangkah lebih jauh, sangat disarankan untuk melihat Ikhtisar Manifes Aplikasi terlebih dahulu.

Ini memberikan gambaran umum tentang komponen dasar file manifes dan fungsinya.

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

Sebuah snapshot disertakan di sini untuk kenyamanan:

<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 komentar pilihan pada 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 pengidentifikasi unik yang digunakan kerangka 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, tidak bergantung pada paket aplikasi yang diuji, nama paket yang berbeda harus digunakan: satu konvensi umum adalah menambahkan akhiran .test .

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

Perlu diketahui juga bahwa meskipun nama paket biasanya memiliki gaya yang sama dengan nama paket Java, sebenarnya hanya ada sedikit hubungannya dengan nama tersebut. Dengan kata lain, paket aplikasi (atau pengujian) Anda mungkin berisi kelas dengan nama paket apa pun, namun di sisi lain, Anda dapat memilih kesederhanaan dan memiliki nama paket Java tingkat atas di aplikasi atau pengujian Anda yang identik dengan nama paket aplikasi.

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

Hal ini diperlukan untuk semua pengujian Instrumentasi karena kelas terkait dikemas dalam file pustaka jar kerangka kerja terpisah, oleh karena itu memerlukan entri jalur kelas tambahan saat paket pengujian dipanggil oleh kerangka aplikasi.

android:targetPackage="com.android.shell"

Ini menetapkan paket target instrumentasi ke com.android.shell . Saat instrumentasi dipanggil melalui perintah am instrument , framework akan memulai ulang proses com.android.shell , dan memasukkan kode instrumentasi ke dalam proses untuk eksekusi pengujian. Ini juga berarti bahwa kode pengujian akan memiliki akses ke semua instance kelas yang berjalan di aplikasi yang diuji dan mungkin dapat memanipulasi status bergantung pada kait 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 instruksi pengemasan. Dalam kebanyakan kasus, opsi file Cetak Biru berbasis Soong sudah cukup. Lihat Konfigurasi Pengujian Sederhana untuk detailnya.

File konfigurasi yang rumit

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

Konfigurasi pengujian dapat menentukan opsi pengaturan perangkat khusus dan argumen default untuk menyediakan kelas pengujian.

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

Sebuah snapshot disertakan di sini untuk kenyamanan:

<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 komentar pilihan pada file konfigurasi pengujian:

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

Ini memberitahu Federasi Perdagangan untuk menginstal ShellTests.apk ke perangkat target menggunakan target_preparer yang ditentukan. Ada banyak pembuat target yang tersedia bagi pengembang di Federasi Perdagangan dan ini dapat digunakan untuk memastikan perangkat telah dikonfigurasi dengan benar sebelum pelaksanaan 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 kelas pengujian Federasi Perdagangan yang akan digunakan untuk menjalankan pengujian dan meneruskan paket pada perangkat yang akan dieksekusi dan kerangka test runner yang dalam hal ini adalah JUnit.

Lihat di sini untuk informasi selengkapnya tentang Konfigurasi Modul Uji

Fitur JUnit4

Menggunakan pustaka android-support-test sebagai test runner memungkinkan adopsi kelas pengujian gaya JUnit4 yang baru, dan contoh perubahan gerrit berisi beberapa penggunaan fitur-fiturnya yang sangat mendasar.

Kode sumber terbaru untuk contoh perubahan gerrit 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 yang signifikan dalam JUnit4 adalah bahwa pengujian tidak lagi diperlukan untuk mewarisi kelas pengujian dasar yang umum; sebagai gantinya, Anda menulis pengujian di kelas Java biasa dan menggunakan anotasi untuk menunjukkan pengaturan dan batasan pengujian tertentu. Dalam contoh ini, kami menginstruksikan agar kelas ini dijalankan sebagai pengujian Android JUnit4.

Anotasi @SmallTest menentukan ukuran pengujian untuk seluruh kelas pengujian: semua metode pengujian yang ditambahkan ke kelas pengujian ini mewarisi anotasi ukuran pengujian ini. penyiapan kelas sebelum pengujian, pembongkaran pasca pengujian, dan pembongkaran kelas pasca pengujian: mirip dengan metode setUp dan tearDown di JUnit4. Anotasi Test digunakan untuk memberi anotasi pada tes yang sebenarnya.

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

Anotasi @Before digunakan pada metode JUnit4 untuk melakukan pengaturan pra-tes. Meskipun tidak digunakan dalam contoh ini, ada juga @After untuk pembongkaran post test. Demikian pula, anotasi @BeforeClass dan @AfterClass dapat digunakan pada metode JUnit4 untuk melakukan penyiapan sebelum menjalankan semua pengujian di kelas pengujian, dan pembongkaran setelahnya. Perhatikan bahwa metode penyiapan dan pembongkaran cakupan kelas harus statis.

Sedangkan untuk metode pengujian, tidak seperti JUnit versi sebelumnya, metode tersebut tidak perlu lagi mengawali nama metode dengan test , melainkan masing-masing metode harus dianotasi dengan @Test . Seperti biasa, metode pengujian harus bersifat publik, menyatakan tidak ada nilai kembalian, tidak mengambil parameter, dan boleh mengeluarkan pengecualian.

        Context context = InstrumentationRegistry.getTargetContext();

Karena pengujian JUnit4 tidak lagi memerlukan kelas dasar umum, maka tidak perlu lagi mendapatkan instance Context melalui getContext() atau getTargetContext() melalui metode kelas dasar; sebagai gantinya, test runner baru mengelolanya melalui InstrumentationRegistry tempat pengaturan kontekstual dan lingkungan yang dibuat oleh kerangka instrumentasi disimpan. Melalui kelas ini, Anda juga dapat menghubungi:

  • getInstrumentation() : turunan ke kelas Instrumentation
  • getArguments() : argumen baris perintah diteruskan ke am instrument melalui -e <key> <value>

Bangun dan uji secara lokal

Untuk kasus penggunaan paling umum, gunakan Atest .

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