Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Menargetkan Contoh Aplikasi

Kategori uji instrumentasi ini tidak jauh berbeda dengan yang menargetkan aplikasi Android biasa. Perlu dicatat 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 konsep, silakan baca melalui platform pengujian pendahuluan .

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 tes instrumentasi akan menargetkan aplikasi, konvensi ini adalah untuk menempatkan kode sumber tes dalam tests direktori di bawah root direktori sumber komponen Anda di pohon source platform.

Lihat pembahasan lebih lanjut tentang lokasi sumber di contoh end-to-end untuk tes diri instrumenting .

File manifes

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

Sebelum melangkah lebih jauh, itu sangat dianjurkan untuk pergi melalui App Manifest Ikhtisar pertama.

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 pilih pada file manifes:

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

The package atribut adalah nama paket aplikasi: ini adalah pengenal unik bahwa Android menggunakan kerangka aplikasi 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 tes, independen dari paket aplikasi yang diuji, nama paket yang berbeda harus digunakan: satu konvensi umum adalah dengan menambahkan akhiran .test .

Selanjutnya, ini package atribut adalah sama dengan apa yang ComponentName#getPackageName() kembali, dan juga sama akan Anda gunakan untuk berinteraksi dengan berbagai pm sub perintah 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 untuk com.android.shell . Ketika instrumentasi dipanggil melalui am instrument perintah, kerangka restart com.android.shell proses, dan kode menyuntikkan instrumentasi ke dalam proses untuk pelaksanaan tes. Ini juga berarti bahwa kode pengujian akan memiliki akses ke semua instance kelas yang berjalan di 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 build dengan metadata modul, dependensi waktu kompilasi, dan instruksi pengemasan. Dalam kebanyakan kasus, opsi file Blueprint berbasis Soong sudah cukup. Lihat Sederhana Uji Konfigurasi untuk rincian.

File konfigurasi kompleks

Untuk tes yang lebih kompleks, Anda juga perlu menulis file konfigurasi tes untuk Android memanfaatkan tes, Federasi Perdagangan .

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

Versi terbaru dari file konfigurasi untuk perubahan Gerrit sampel dapat diakses di: kerangka / base / paket / Shell / tes / 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 pilih 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 Uji Modul Configs

fitur JUnit4

Menggunakan android-support-test perpustakaan sebagai runner tes memungkinkan adoptation kelas uji gaya JUnit4 baru, dan perubahan Gerrit sampel berisi beberapa penggunaan yang sangat dasar fitur-fiturnya.

Source code terbaru untuk perubahan Gerrit sampel dapat diakses di: kerangka / base / paket / Shell / tes / 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.

The @SmallTest penjelasan ditentukan ukuran tes untuk seluruh kelas uji: semua metode pengujian ditambahkan ke dalam kelas tes ini mewarisi tes ini ukuran penjelasan. 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. Test penjelasan digunakan untuk annotating tes yang sebenarnya.

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

The @Before penjelasan digunakan pada metode oleh JUnit4 untuk melakukan setup tes pra. Meskipun tidak digunakan dalam contoh ini, ada juga @After untuk post test 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 penyiapan ruang lingkup kelas dan pembongkaran harus statis.

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

        Context context = InstrumentationRegistry.getTargetContext();

Karena JUnit4 tes tidak lagi memerlukan kelas dasar umum, itu tidak lagi diperlukan untuk memperoleh Context contoh melalui getContext() atau getTargetContext() melalui metode kelas dasar; sebaliknya, pelari tes baru berhasil mereka melalui InstrumentationRegistry mana pengaturan kontekstual dan lingkungan yang dibuat oleh kerangka instrumentasi disimpan. Melalui kelas ini, Anda juga dapat menelepon:

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

Bangun dan uji secara lokal

Untuk sebagian besar kasus penggunaan umum, mempekerjakan atest .

Untuk kasus yang lebih kompleks yang membutuhkan kustomisasi lebih berat, ikuti petunjuk instrumentasi .