Google berkomitmen untuk memajukan ekuitas ras untuk komunitas kulit hitam. Lihat bagaimana.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Menargetkan Contoh Aplikasi

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

Perhatikan bahwa panduan ini mengasumsikan bahwa Anda sudah memiliki 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 tes instrumentasi baru dengan paket target yang ditetapkan pada paket aplikasi tesnya sendiri. Jika Anda tidak terbiasa dengan konsep ini, silakan baca pengantar pengujian Platform .

Panduan ini menggunakan tes tindak untuk dijadikan sampel:

  • kerangka kerja / basis / paket / Shell / tes

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

Menentukan lokasi sumber

Karena tes instrumentasi akan menargetkan aplikasi, konvensi ini adalah menempatkan kode sumber tests direktori tests bawah root direktori sumber komponen Anda di platform source tree.

Lihat lebih banyak diskusi tentang lokasi sumber dalam contoh ujung-ke-ujung untuk tes swa-instruksi .

File manifes

Sama seperti aplikasi biasa, setiap modul uji instrumentasi memerlukan file manifes. Jika Anda memberi nama file tersebut sebagai AndroidManifest.xml dan menyediakannya di sebelah Android.mk untuk modul pengujian Anda, file itu akan dimasukkan secara otomatis oleh BUILD_PACKAGE inti makefile.

Sebelum melangkah lebih jauh, sangat disarankan untuk menelusuri App Manifest Overview terlebih dahulu.

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

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

Cuplikan 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 pilih 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 itu.

Karena ini adalah paket aplikasi pengujian, terlepas 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 apa yang ComponentName#getPackageName() , dan juga sama dengan yang Anda gunakan untuk berinteraksi dengan berbagai perintah sub pm melalui adb shell .

Harap perhatikan juga bahwa walaupun nama paket biasanya dengan gaya yang sama dengan nama paket Java, sebenarnya ada beberapa hal yang harus dilakukan. Dengan kata lain, paket aplikasi Anda (atau tes) dapat berisi kelas dengan nama paket apa pun, meskipun di sisi lain, Anda dapat memilih untuk kesederhanaan dan memiliki nama paket Java tingkat atas Anda dalam aplikasi Anda atau tes identik dengan nama paket aplikasi.

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

Ini diperlukan untuk semua tes Instrumentasi karena kelas terkait dikemas dalam file pustaka kerangka kerja yang terpisah, oleh karena itu memerlukan entri classpath tambahan ketika paket tes dipanggil oleh kerangka kerja aplikasi.

 android:targetPackage="com.android.shell"
 

Ini menetapkan paket target instrumentasi ke com.android.shell.tests . Ketika instrumentasi dipanggil melalui perintah am instrument , kerangka kerja memulai kembali proses com.android.shell.tests , dan menyuntikkan kode instrumentasi ke dalam proses untuk pelaksanaan pengujian. Ini juga berarti bahwa kode tes akan memiliki akses ke semua instance kelas yang berjalan dalam aplikasi yang sedang diuji dan mungkin dapat memanipulasi keadaan tergantung pada kait tes yang terbuka.

File konfigurasi sederhana

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

File konfigurasi yang kompleks

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 uji.

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

Cuplikan 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 pilih pada file konfigurasi pengujian:

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

Ini memberi tahu Federasi Dagang untuk menginstal ShellTests.apk ke perangkat target menggunakan target_preparer yang ditentukan. Ada banyak penyusun target yang tersedia bagi pengembang di Federasi Dagang dan ini dapat digunakan untuk memastikan perangkat diatur dengan benar sebelum menguji pelaksanaan.

 <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 tes dan meneruskan paket pada perangkat yang akan dieksekusi dan kerangka uji pelari yang JUnit dalam kasus ini.

Lihat di sini untuk informasi lebih lanjut tentang Konfigurasi Modul Tes

Fitur JUnit4

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

Kode sumber terbaru untuk perubahan sampel 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 bermanfaat secara umum.

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

Perbedaan signifikan dalam JUnit4 adalah bahwa tes tidak lagi diperlukan untuk mewarisi dari kelas tes dasar biasa; alih-alih, Anda menulis tes di kelas Java biasa dan menggunakan anotasi untuk menunjukkan pengaturan dan kendala tes tertentu. Dalam contoh ini, kami menginstruksikan bahwa kelas ini harus dijalankan sebagai tes Android JUnit4.

Anotasi @SmallTest menentukan ukuran uji untuk seluruh kelas uji: semua metode uji yang ditambahkan ke kelas uji ini mewarisi anotasi ukuran uji ini. pre tes setup kelas, post test air mata ke bawah, dan post test kelas air mata ke bawah: mirip dengan setUp dan tearDown metode dalam JUnit4. Anotasi Test digunakan untuk menjelaskan tes yang sebenarnya.

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

Penjelasan @Before digunakan pada metode oleh JUnit4 untuk melakukan pengaturan pra tes. Meskipun tidak digunakan dalam contoh ini, ada juga @After untuk tes pasca teardown. Demikian pula, @BeforeClass dan @AfterClass penjelasan yang dapat digunakan pada metode oleh JUnit4 untuk melakukan pengaturan sebelum mengeksekusi semua tes di kelas tes, dan teardown setelah itu. Perhatikan bahwa metode pengaturan kelas dan teardown harus statis.

Adapun metode pengujian, tidak seperti dalam versi JUnit sebelumnya, mereka tidak perlu lagi memulai nama metode dengan test , sebaliknya, masing-masing dari mereka harus diberi penjelasan dengan @Test . Seperti biasa, metode pengujian harus bersifat publik, menyatakan tidak ada nilai balik, tidak mengambil parameter, dan dapat memberikan pengecualian.

         Context context = InstrumentationRegistry.getTargetContext();
 

Karena tes JUnit4 tidak lagi memerlukan kelas dasar umum, tidak perlu lagi untuk mendapatkan instance Context melalui getContext() atau getTargetContext() melalui metode kelas dasar; sebagai gantinya, pelari uji baru mengelola mereka melalui InstrumentationRegistry mana pengaturan kontekstual dan lingkungan yang dibuat oleh kerangka kerja instrumentasi disimpan. Melalui kelas ini, Anda juga dapat menghubungi:

  • getInstrumentation() : instance ke kelas Instrumentation
  • getArguments() : argumen baris perintah 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 membutuhkan penyesuaian lebih berat, ikuti instruksi instrumentasi .