Menargetkan contoh aplikasi

Kategori uji instrumentasi ini tidak jauh berbeda dengan penargetan yang aplikasi Android biasa. Perlu diperhatikan bahwa aplikasi pengujian yang mencakup instrumentasi harus ditandatangani dengan sertifikat yang sama sebagai aplikasi yang ditargetkannya.

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

Panduan ini menggunakan pengujian berikut sebagai contoh:

• framework/dasar/paket/Shell/pengujian

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

Menentukan lokasi sumber

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

Lihat diskusi lebih lanjut tentang lokasi sumber di contoh menyeluruh untuk uji instrumentasi mandiri.

File manifes

Sama seperti aplikasi biasa, setiap modul uji instrumentasi memerlukan manifes. Jika Anda memberi nama file sebagai AndroidManifest.xml dan memberikannya berikutnya ke Android.mk untuk modul pengujian Anda, modul ini akan disertakan secara otomatis oleh Makefile inti BUILD_PACKAGE.

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

Ini memberikan gambaran umum tentang komponen dasar dari file manifes dan fungsionalitas.

Versi terbaru file manifes untuk contoh perubahan gerrit dapat diakses di: https://android.googlesource.com/platform/frameworks/base/+/main/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 komentar tertentu 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 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, terpisah dari aplikasi paket yang sedang diuji, nama paket yang berbeda harus digunakan: satu konvensi umum adalah menambahkan akhiran .test.

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

Perhatikan juga bahwa meskipun nama paket biasanya memiliki gaya yang sama sebagai nama paket Java, sebenarnya hanya ada sedikit keterkaitan dengannya. Di kata, paket aplikasi (atau pengujian) Anda dapat berisi class dengan paket apa pun lengkap, meskipun di sisi lain, Anda dapat memilih kesederhanaan dan memiliki nama paket Java level dalam aplikasi atau pengujian identik dengan aplikasi nama paket.

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

Ini diperlukan untuk semua Uji instrumentasi karena class terkait dikemas dalam file library jar framework terpisah, sehingga memerlukan entri classpath saat paket pengujian dipanggil oleh framework aplikasi.

android:targetPackage="com.android.shell"

Tindakan ini menetapkan paket target instrumentasi ke com.android.shell. Saat instrumentasi dipanggil melalui perintah am instrument, framework memulai ulang proses com.android.shell, dan memasukkan kode instrumentasi ke dalam proses untuk menjalankan uji coba. Ini juga berarti bahwa kode pengujian akan memiliki akses ke semua instance class yang berjalan di aplikasi yang sedang diuji dan dapat dapat memanipulasi status tergantung 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 paket petunjuk. Pada umumnya, opsi file {i>Blueprint <i}berbasis Soong memadai. Lihat Konfigurasi Pengujian Sederhana untuk mengetahui detailnya.

File konfigurasi kompleks

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

Konfigurasi pengujian dapat menentukan opsi penyiapan perangkat khusus dan setelan default argumen 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 komentar tertentu dalam file konfigurasi pengujian:

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

Tindakan ini akan memberi tahu Federasi Perdagangan untuk menginstal ShellTests.apk ke target perangkat menggunakan target_preparer yang ditentukan. Ada banyak persiapan target tersedia untuk developer di Federasi Perdagangan dan ini dapat digunakan untuk memastikan perangkat disiapkan dengan benar sebelum eksekusi uji coba.

<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 uji Federasi Perdagangan yang akan digunakan untuk menjalankan pengujian dan meneruskan paket pada perangkat yang akan dieksekusi dan runner pengujian yakni JUnit dalam kasus ini.

Lihat di sini untuk mengetahui informasi selengkapnya tentang Konfigurasi Modul Pengujian

Fitur JUnit4

Dengan menggunakan library android-support-test sebagai runner pengujian, Anda dapat mengadopsi Kelas pengujian gaya JUnit4, dan perubahan gerrit sampel berisi beberapa penggunaan fitur-fiturnya.

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

Walaupun pola pengujian biasanya hanya untuk tim komponen, ada beberapa pola penggunaan yang umumnya berguna.

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

Perbedaan yang signifikan di JUnit4 adalah pengujian tidak lagi diperlukan untuk diwarisi dari class pengujian dasar yang umum; sebagai gantinya, Anda menulis pengujian dalam class Java biasa dan menggunakan anotasi untuk menunjukkan penyiapan dan batasan pengujian tertentu. Di beberapa contoh ini, kami menginstruksikan bahwa class ini harus dijalankan sebagai Android Pengujian 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, penghapusan setelah pengujian, dan penghapusan class pasca-pengujian: mirip dengan metode setUp dan tearDown di JUnit4. Anotasi Test digunakan untuk menganotasi pengujian yang 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 pembongkaran pasca-pengujian. Demikian pula, anotasi @BeforeClass dan @AfterClass dapat digunakan di oleh JUnit4 untuk melakukan pengaturan sebelum mengeksekusi semua pengujian dalam kelas pengujian, dan pembongkaran setelahnya. Perhatikan bahwa metode penyiapan dan penghapusan cakupan class harus bersifat statis.

Untuk metode pengujian, tidak seperti di JUnit versi sebelumnya, metode tersebut tidak perlu lagi memulai nama metode dengan test, tetapi masing-masing harus dianotasi dengan @Test. Seperti biasa, metode pengujian harus bersifat publik, mendeklarasikan nilai yang ditampilkan, tidak mengambil parameter, dan dapat melemparkan pengecualian.

        Context context = InstrumentationRegistry.getTargetContext();

Karena pengujian JUnit4 tidak lagi memerlukan class dasar umum, maka yang diperlukan untuk mendapatkan instance Context melalui getContext() atau getTargetContext() melalui metode class dasar; sebagai gantinya, runner pengujian baru mengelolanya melalui InstrumentationRegistry dengan konfigurasi kontekstual dan lingkungan yang dibuat oleh framework instrumentasi disimpan. Melalui kelas ini, Anda juga dapat memanggil:

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

Membangun dan menguji secara lokal

Untuk kasus penggunaan yang paling umum, gunakan Atest.

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