Contoh tes instrumentasi mandiri

Ketika pengujian instrumentasi dimulai, paket targetnya dimulai ulang dengan kode instrumentasi yang dimasukkan dan dimulai untuk eksekusi. Satu pengecualian adalah bahwa paket target di sini tidak boleh berupa kerangka aplikasi Android itu sendiri, seperti paket android , karena hal ini akan mengarah pada situasi paradoks di mana kerangka Android perlu di-restart, yang mendukung fungsi-fungsi sistem, termasuk instrumentasi itu sendiri.

Artinya pengujian instrumentasi tidak dapat dimasukkan ke dalam framework Android, alias server sistem, untuk dieksekusi. Untuk menguji framework Android, kode pengujian hanya dapat memanggil permukaan API publik, atau permukaan yang diekspos menggunakan AIDL Bahasa Definisi Antarmuka Android yang tersedia di pohon sumber platform. Untuk kategori pengujian ini, tidak ada gunanya menargetkan paket tertentu. Oleh karena itu, biasanya instrumentasi tersebut dideklarasikan untuk menargetkan paket aplikasi pengujiannya sendiri, sebagaimana ditentukan dalam tag <manifest> -nya sendiri pada AndroidManifest.xml .

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

  • Gabungkan aktivitas yang diperlukan untuk pengujian.
  • Bagikan ID pengguna dengan sistem.
  • Ditandatangani dengan kunci platform.
  • Dikompilasi berdasarkan sumber kerangka kerja, bukan SDK publik.

Kategori tes instrumentasi ini kadang-kadang disebut sebagai instrumentasi mandiri. Berikut beberapa contoh pengujian instrumentasi 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 gambaran kasar sebelum melanjutkan.

Tentukan lokasi sumber

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

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

Karena Anda menambahkan pengujian baru, Anda mungkin perlu membuat direktori tests di samping komponen src , dan mengisinya dengan konten.

Dalam beberapa kasus, tim Anda mungkin memiliki struktur direktori lebih lanjut yang sedang tests karena kebutuhan untuk mengemas rangkaian pengujian yang berbeda ke dalam apk individual. Dan dalam hal ini, Anda harus membuat sub direktori baru di bawah tests .

Terlepas dari strukturnya, Anda akan mengisi direktori tests atau sub direktori yang baru dibuat dengan file yang serupa dengan yang ada di direktori instrumentation dalam contoh perubahan gerrit. Detail setiap file dijelaskan nanti di dokumen ini.

File manifes

Seperti halnya proyek aplikasi, setiap modul pengujian instrumentasi memerlukan file manifes bernama AndroidManifest.xml . Untuk menyertakan file ini secara otomatis menggunakan makefile inti BUILD_PACKAGE , sediakan file ini di samping file Android.mk untuk modul pengujian Anda.

Jika Anda belum familiar dengan file AndroidManifest.xml , lihat Ikhtisar Manifes Aplikasi

Berikut ini contoh file AndroidManifest.xml :

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

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

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

</manifest>

Beberapa komentar pilihan pada file manifes:

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

Atribut package adalah nama paket aplikasi: ini adalah pengidentifikasi unik yang digunakan kerangka 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.

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

Perhatikan bahwa meskipun nama paket biasanya memiliki gaya yang sama dengan nama paket Java, sebenarnya hanya ada sedikit hubungannya dengan nama tersebut. Dengan kata lain, paket aplikasi (atau pengujian) Anda mungkin berisi kelas dengan nama paket apa pun, namun di sisi lain, Anda dapat memilih kesederhanaan dan memiliki nama paket Java tingkat atas di aplikasi atau pengujian Anda yang identik dengan nama paket aplikasi.

android:sharedUserId="android.uid.system"

Ini menyatakan bahwa pada waktu instalasi, file APK ini harus diberikan ID pengguna yang sama, yaitu identitas runtime, sebagai platform inti. Perhatikan bahwa ini bergantung pada apk yang ditandatangani dengan sertifikat yang sama dengan platform inti (lihat LOCAL_CERTIFICATE di bagian sebelumnya), namun konsepnya berbeda:

  • beberapa izin atau API dilindungi tanda tangan, sehingga memerlukan sertifikat penandatanganan yang sama
  • beberapa izin atau API memerlukan identitas pengguna system pemanggil, yang memerlukan paket panggilan untuk berbagi ID pengguna dengan system , jika itu merupakan paket terpisah dari platform inti itu sendiri
<uses-library android:name="android.test.runner" />

Hal ini diperlukan untuk semua pengujian Instrumentasi karena kelas terkait dikemas dalam file pustaka JAR kerangka kerja terpisah, oleh karena itu memerlukan entri jalur kelas tambahan saat paket pengujian dipanggil oleh kerangka aplikasi.

android:targetPackage="android.test.example.helloworld"

Anda mungkin telah memperhatikan bahwa targetPackage di sini dinyatakan sama dengan atribut package yang dinyatakan dalam tag manifest file ini. Seperti disebutkan dalam dasar-dasar pengujian , kategori pengujian instrumentasi ini biasanya ditujukan untuk menguji API kerangka kerja, sehingga tidak terlalu berarti bagi mereka untuk memiliki paket aplikasi bertarget spesifik, selain paket aplikasi 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 Cetak Biru berbasis Soong sudah cukup. Untuk detailnya, lihat Konfigurasi Pengujian Sederhana .

File konfigurasi yang rumit

Untuk kasus yang lebih kompleks ini, 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 menyediakan kelas pengujian. Lihat contohnya 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 pilihan 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 pembuat target yang tersedia bagi pengembang di Federasi Perdagangan dan ini dapat digunakan untuk memastikan perangkat telah dikonfigurasi dengan benar sebelum pelaksanaan 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 meneruskan paket pada perangkat yang akan dieksekusi dan kerangka test runner yang dalam hal ini adalah JUnit.

Untuk informasi lebih lanjut, lihat Konfigurasi Modul Uji .

Fitur JUnit4

Menggunakan pustaka android-support-test sebagai test runner memungkinkan penerapan kelas pengujian gaya JUnit4 yang baru, dan contoh perubahan gerrit berisi beberapa penggunaan fitur-fiturnya yang sangat mendasar. Lihat contohnya di /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java .

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

@RunWith(JUnit4.class)
public class HelloWorldTest {

Perbedaan yang signifikan dalam JUnit4 adalah bahwa pengujian tidak lagi diperlukan untuk mewarisi kelas pengujian dasar yang 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() {
    ...

Anotasi @Before dan @After digunakan pada metode JUnit4 untuk melakukan penyiapan pra pengujian dan pembongkaran pasca pengujian. Demikian pula, anotasi @BeforeClass dan @AfterClass digunakan pada metode JUnit4 untuk melakukan penyiapan sebelum menjalankan semua pengujian di kelas pengujian, dan pembongkaran setelahnya. Perhatikan bahwa metode penyiapan dan pembongkaran cakupan kelas harus statis. Sedangkan untuk metode pengujian, tidak seperti JUnit versi sebelumnya, metode tersebut tidak perlu lagi mengawali nama metode dengan test , melainkan masing-masing metode harus dianotasi dengan @Test . Seperti biasa, metode pengujian harus bersifat publik, menyatakan tidak ada nilai kembalian, tidak mengambil parameter, dan boleh mengeluarkan pengecualian.

Akses kelas instrumentasi

Meskipun tidak tercakup dalam contoh dasar hello world, pengujian Android biasanya memerlukan akses. Contoh Instrumentation : ini adalah antarmuka API inti yang menyediakan akses ke konteks aplikasi, API pengujian terkait siklus hidup aktivitas, dan banyak lagi.

Karena pengujian JUnit4 tidak lagi memerlukan kelas dasar yang umum, maka tidak perlu lagi mendapatkan instans Instrumentation melalui InstrumentationTestCase#getInstrumentation() , sebagai gantinya, runner pengujian baru mengelolanya melalui InstrumentationRegistry tempat penyiapan kontekstual dan lingkungan yang dibuat oleh kerangka instrumentasi disimpan.

Untuk mengakses instance kelas Instrumentation , cukup panggil metode statis getInstrumentation() pada kelas InstrumentationRegistry :

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

Bangun dan uji secara lokal

Untuk kasus penggunaan paling umum, gunakan Atest .

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