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

Contoh Tes Instrumen Sendiri

Ketika tes instrumentasi dimulai, paket targetnya dimulai ulang dengan kode instrumentasi yang disuntikkan dan dimulai untuk dieksekusi. Satu pengecualian adalah bahwa paket sasaran disini tidak bisa menjadi kerangka aplikasi Android itu sendiri, yaitu paket android , karena hal itu akan mengarah pada situasi paradoks di mana kerangka Android akan perlu di-restart, yang adalah apa yang mendukung fungsi sistem, termasuk instrumentasi diri.

Ini berarti bahwa pengujian instrumentasi tidak dapat memasukkan dirinya sendiri ke dalam kerangka kerja Android, alias server sistem, untuk dieksekusi. Untuk menguji kerangka Android, kode tes dapat meminta permukaan API hanya publik, atau mereka yang terpapar melalui Android Interface Definition Bahasa AIDL tersedia di pohon source platform. Untuk kategori pengujian ini, tidak ada gunanya menargetkan paket tertentu. Oleh karena itu, adat itu untuk instrumentasi tersebut untuk dinyatakan menargetkan paket aplikasi tes sendiri, sebagaimana ditetapkan dalam sendiri <manifest> tag dari AndroidManifest.xml .

Tergantung pada persyaratannya, paket aplikasi uji dalam kategori ini juga dapat:

  • Bundel aktivitas yang diperlukan untuk pengujian.
  • Bagikan ID pengguna dengan sistem.
  • Ditandatangani dengan kunci platform.
  • Dikompilasi terhadap sumber kerangka kerja daripada SDK publik.

Kategori tes instrumentasi ini kadang-kadang disebut sebagai instrumentasi mandiri. Berikut adalah beberapa contoh pengujian instrumen mandiri di sumber platform:

Contoh yang dibahas di sini adalah menulis pengujian instrumentasi baru dengan paket target yang ditetapkan pada paket aplikasi pengujiannya sendiri. Panduan ini menggunakan tes berikut sebagai contoh:

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

Menentukan lokasi sumber

Biasanya tim Anda sudah memiliki pola tempat untuk memeriksa kode, dan tempat untuk menambahkan tes. Sebagian besar tim memiliki repositori git tunggal, atau berbagi satu dengan tim lain tetapi memiliki sub direktori khusus yang berisi kode sumber komponen.

Dengan asumsi lokasi root untuk sumber komponen Anda di <component source root> , sebagian besar komponen memiliki src dan tests folder di bawahnya, dan beberapa file tambahan seperti Android.mk (atau dipecah menjadi tambahan .mk file), file manifest AndroidManifest.xml , dan tes file konfigurasi 'AndroidTest.xml'.

Karena Anda menambahkan tes baru, Anda mungkin perlu untuk membuat tests direktori samping komponen Anda src , dan mengisi dengan konten.

Dalam beberapa kasus, tim Anda mungkin memiliki struktur direktori lebih lanjut di bawah tests karena kebutuhan untuk paket suite berbeda dari tes ke apks individu. Dan dalam hal ini, Anda harus membuat sub direktori baru di bawah tests .

Terlepas dari struktur, Anda akan berakhir mempopulasikan tests direktori atau sub direktori yang baru dibuat dengan file yang mirip dengan apa yang ada di instrumentation direktori dalam perubahan Gerrit sampel. Bagian di bawah ini akan menjelaskan detail lebih lanjut dari setiap file.

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 modul tes 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. Lihat contoh di platform_testing / tes / contoh / instrumentasi / AndroidManifest.xml .

Sebuah snapshot disertakan di sini untuk kenyamanan:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

    <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />

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

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

Beberapa komentar pilih pada file manifes:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

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.

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.

android:sharedUserId="android.uid.system"

Ini menyatakan bahwa pada saat penginstalan, apk ini harus diberikan id pengguna yang sama, yaitu identitas runtime, sebagai platform inti. Perhatikan bahwa ini tergantung pada apk ditandatangani dengan sertifikat yang sama sebagai platform inti (lihat LOCAL_CERTIFICATE di bagian atas), namun mereka adalah konsep yang berbeda:

  • beberapa izin atau API dilindungi tanda tangan, yang memerlukan sertifikat penandatanganan yang sama
  • beberapa izin atau API membutuhkan system identitas pengguna dari penelepon, yang membutuhkan paket menelepon untuk berbagi user id dengan system , jika paket terpisah dari platform inti itu sendiri
<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="android.test.example.helloworld"

Anda mungkin telah memperhatikan bahwa targetPackage sini dinyatakan sama dengan package atribut dinyatakan dalam manifest tag dari file ini. Seperti disebutkan dalam pengujian dasar , kategori ini uji instrumentasi biasanya ditujukan untuk menguji API kerangka kerja, sehingga tidak sangat berarti bagi mereka untuk memiliki paket aplikasi tertentu yang ditargetkan, lain maka itu sendiri.

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. Untuk rincian, lihat Simple Uji Konfigurasi .

File konfigurasi kompleks

Untuk kasus-kasus 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. Lihat contoh di /platform_testing/tests/example/instrumentation/AndroidTest.xml .

Sebuah snapshot disertakan di sini untuk kenyamanan:

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <test class="com.android.tradefed.testtype.AndroidJUnitTest">
    <option name="package" value="android.test.example.helloworld"/>
    <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="HelloWorldTests.apk"/>
</target_preparer>

Ini memberitahu Federasi Perdagangan untuk menginstal HelloWorldTests.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="android.test.example.helloworld"/>
  <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.

Untuk informasi lebih lanjut, lihat Uji Modul Configs .

fitur JUnit4

Menggunakan android-support-test perpustakaan sebagai runner tes memungkinkan adopsi kelas tes gaya JUnit4 baru, dan perubahan Gerrit sampel berisi beberapa penggunaan yang sangat dasar fitur-fiturnya. Lihat contoh di /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java .

Sementara pola pengujian biasanya khusus untuk tim komponen, ada beberapa pola penggunaan yang umumnya berguna.

@RunWith(JUnit4.class)
public class HelloWorldTest {

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

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

The @Before dan @After penjelasan yang digunakan pada metode oleh JUnit4 untuk melakukan setup tes pre dan post test teardown. Demikian pula, @BeforeClass dan @AfterClass penjelasan yang 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.

Penting: metode uji sendiri dijelaskan dengan @Test penjelasan; dan catatan bahwa untuk tes yang akan dijalankan melalui APCT, mereka harus dijelaskan dengan ukuran uji: contoh dijelaskan metode testHelloWorld sebagai @SmallTest . Anotasi dapat diterapkan pada lingkup metode, atau lingkup kelas.

mengakses instrumentation

Meskipun tidak tercakup dalam contoh halo dunia dasar, itu cukup umum untuk tes Android membutuhkan akses Instrumentation contoh: ini adalah antarmuka API inti yang menyediakan akses ke konteks aplikasi, aktivitas siklus hidup terkait API tes dan banyak lagi.

Karena JUnit4 tes tidak lagi memerlukan kelas dasar umum, itu tidak lagi diperlukan untuk mendapatkan Instrumentation misalnya melalui InstrumentationTestCase#getInstrumentation() , sebaliknya, runner tes baru berhasil melalui InstrumentationRegistry mana pengaturan kontekstual dan lingkungan yang dibuat oleh kerangka instrumentasi disimpan.

Untuk mengakses contoh Instrumentation kelas, hanya memanggil metode statis getInstrumentation() pada InstrumentationRegistry kelas:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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 .