Menargetkan Contoh Aplikasi

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

Perhatikan bahwa panduan ini mengasumsikan bahwa Anda sudah memiliki beberapa pengetahuan dalam alur kerja pohon sumber platform. Jika tidak, silakan merujuk ke https://source.android.com/source/requirements. Contoh yang dibahas di sini adalah menulis pengujian instrumentasi baru dengan paket target yang ditetapkan pada paket aplikasi pengujiannya sendiri. Jika Anda tidak terbiasa dengan konsepnya, silakan baca pengantar pengujian Platform .

Panduan ini menggunakan tes berikut untuk dijadikan sebagai sampel:

• kerangka kerja/dasar/paket/Shell/tes

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

Menentukan lokasi sumber

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

Lihat diskusi lebih lanjut tentang lokasi sumber dalam contoh ujung ke ujung untuk pengujian instrumen mandiri .

File manifes

Sama seperti aplikasi biasa, setiap modul pengujian instrumentasi membutuhkan file manifes. Jika Anda menamai file sebagai AndroidManifest.xml dan menyediakannya di sebelah Android.mk untuk modul pengujian Anda, itu akan disertakan secara otomatis oleh makefile inti BUILD_PACKAGE .

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

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

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

Lebih lanjut, atribut package ini sama dengan yang dikembalikan oleh ComponentName#getPackageName() , dan juga sama yang akan Anda gunakan untuk berinteraksi dengan berbagai sub perintah pm melalui adb shell .

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

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

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

android:targetPackage="com.android.shell"

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 eksekusi pengujian. Ini juga berarti bahwa kode pengujian akan memiliki akses ke semua instance kelas yang berjalan dalam aplikasi yang sedang diuji dan mungkin dapat memanipulasi status tergantung pada kait pengujian yang terbuka.

File konfigurasi sederhana

Setiap modul pengujian baru harus memiliki file konfigurasi untuk mengarahkan sistem pembangunan dengan metadata modul, dependensi waktu kompilasi, dan instruksi pengemasan. Dalam kebanyakan kasus, opsi file Blueprint berbasis Soong sudah cukup. Lihat Konfigurasi Tes Sederhana untuk detailnya.

File konfigurasi kompleks

Penting: Petunjuk di bagian ini hanya diperlukan untuk pengujian CTS atau yang memerlukan pengaturan khusus, seperti menonaktifkan Bluetooth atau mengumpulkan data sampel. Semua kasus lain dapat dicakup melalui Konfigurasi Uji Sederhana . Lihat Konfigurasi Uji Kompleks untuk detail lebih lanjut yang berlaku untuk bagian ini.

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 memasok kelas pengujian.

Versi terbaru dari 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 penyiapan target yang tersedia untuk pengembang di Federasi Perdagangan dan ini dapat digunakan untuk memastikan perangkat diatur 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 kelas pengujian Federasi Perdagangan yang akan digunakan untuk menjalankan pengujian dan lolos dalam paket pada perangkat yang akan dieksekusi dan kerangka kerja runner pengujian yang dalam hal ini adalah JUnit.

Lihat di sini untuk informasi lebih lanjut tentang Konfigurasi Modul Tes

fitur JUnit4

Menggunakan library android-support-test sebagai test runner memungkinkan adopsi kelas pengujian gaya JUnit4 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

Sementara 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 bahwa tes tidak lagi diperlukan untuk mewarisi dari kelas tes dasar 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 bahwa kelas ini harus dijalankan sebagai pengujian Android JUnit4.

Anotasi @SmallTest menetapkan ukuran pengujian untuk seluruh kelas pengujian: semua metode pengujian yang ditambahkan ke kelas pengujian ini mewarisi anotasi ukuran pengujian ini. penyiapan kelas pra 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.

Penting: metode pengujian itu sendiri dijelaskan dengan penjelasan @Test ; dan perhatikan bahwa untuk pengujian yang akan dijalankan melalui APCT, pengujian tersebut harus diberi keterangan dengan ukuran pengujian. Anotasi tersebut dapat diterapkan pada lingkup metode, atau lingkup kelas.

    @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 tes. Demikian pula, anotasi @BeforeClass dan @AfterClass dapat digunakan pada metode oleh JUnit4 untuk melakukan penyiapan sebelum menjalankan semua pengujian di kelas pengujian, dan pembongkaran setelahnya. Perhatikan bahwa metode penyiapan ruang lingkup kelas dan pembongkaran harus statis.

Adapun metode pengujian, tidak seperti di versi JUnit sebelumnya, mereka tidak perlu lagi memulai nama metode dengan test , sebaliknya, masing-masing harus dianotasi dengan @Test . Seperti biasa, metode pengujian harus bersifat publik, menyatakan tidak ada nilai yang dikembalikan, tidak mengambil parameter, dan dapat mengeluarkan pengecualian.

        Context context = InstrumentationRegistry.getTargetContext();

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

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

Bangun dan uji secara lokal

Untuk kasus penggunaan yang paling umum, gunakan Atest .

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