Saat uji instrumentasi dimulai, paket targetnya akan
dimulai ulang dengan kode instrumentasi yang dimasukkan dan dimulai untuk dieksekusi. paket Premium AI
pengecualian adalah bahwa paket target di sini
tidak bisa berupa aplikasi Android
framework itu sendiri, seperti paket android
, karena tindakan itu akan menyebabkan
situasi paradoks di mana kerangka kerja Android harus dimulai ulang,
adalah hal yang mendukung fungsi sistem, termasuk instrumentasi itu sendiri.
Ini berarti uji instrumentasi tidak dapat memasukkan dirinya ke dalam Android
kerangka kerja, alias server sistem, untuk dieksekusi. Untuk menguji Android
kode pengujian hanya dapat memanggil platform API publik, atau platform API
menggunakan Android Interface Definition Language
AIDL
yang tersedia di hierarki sumber platform. Untuk kategori pengujian ini, menargetkan paket tertentu tidak berarti. Oleh karena itu, instrumen
tersebut biasanya dideklarasikan untuk menargetkan paket aplikasi pengujiannya sendiri, seperti
yang ditentukan dalam tag <manifest>
dari AndroidManifest.xml
.
Tergantung pada persyaratannya, paket aplikasi pengujian dalam kategori ini mungkin juga:
- Paketkan aktivitas yang diperlukan untuk pengujian.
- Bagikan ID pengguna ke sistem.
- Ditandatangani dengan kunci platform.
- Dikompilasi terhadap sumber framework, bukan SDK publik.
Kategori uji instrumentasi ini terkadang disebut sebagai instrumentasi mandiri. Berikut adalah beberapa contoh uji instrumentasi mandiri di sumber platform:
Contoh yang dibahas di sini adalah menulis pengujian instrumentasi baru dengan paket target yang ditetapkan di paket aplikasi pengujiannya sendiri. Panduan ini menggunakan hal-hal berikut sebagai contoh:
Sebaiknya jelajahi kode terlebih dahulu untuk mendapatkan tayangan kasar sebelum melanjutkan.
Menentukan lokasi sumber
Biasanya tim Anda sudah memiliki pola tempat untuk melakukan pemeriksaan dalam kode, dan tempat untuk menambahkan pengujian. Sebagian besar tim memiliki satu repositori git, atau berbagi satu dengan tim lain tetapi memiliki sub direktori khusus yang berisi kode sumber komponennya.
Dengan asumsi lokasi root untuk sumber komponen Anda adalah <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
Anda, dan isi dengan konten.
Dalam beberapa kasus, tim Anda mungkin memiliki struktur direktori lebih lanjut di tests
karena perlunya memaketkan rangkaian pengujian yang berbeda ke dalam masing-masing APK. Dan
dalam hal ini, Anda harus membuat subdirektori baru pada tests
.
Terlepas dari strukturnya, Anda pada akhirnya akan mengisi direktori tests
atau
sub direktori yang baru dibuat dengan
file yang mirip dengan yang ada di
instrumentation
dalam perubahan gerrit sampel. Detail setiap
file akan dijelaskan nanti dalam dokumen ini.
File manifes
Seperti project aplikasi, setiap modul pengujian instrumentasi memerlukan
file manifes yang disebut AndroidManifest.xml
. Untuk menyertakan file ini secara otomatis menggunakan makefile inti BUILD_PACKAGE
, berikan file ini di samping file Android.mk
untuk modul pengujian Anda.
Jika Anda tidak terbiasa dengan file AndroidManifest.xml
, lihat
Ringkasan Manifes Aplikasi
Berikut adalah 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 tertentu 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 merupakan atribut unik
yang digunakan framework 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 yang
ComponentName#getPackageName()
dan juga hal yang sama yang akan Anda gunakan untuk berinteraksi dengan berbagai sub-kelompok pm
menggunakan adb shell
.
Perhatikan bahwa meskipun nama paket biasanya memiliki gaya yang sama sebagai nama paket Java, sebenarnya hanya ada sedikit keterkaitan dengannya. Di kata, paket aplikasi (atau pengujian) Anda dapat berisi class dengan paket apa pun lengkap, meskipun di sisi lain, Anda dapat memilih kesederhanaan dan memiliki nama paket Java level dalam aplikasi atau pengujian identik dengan aplikasi nama paket.
android:sharedUserId="android.uid.system"
Ini mendeklarasikan bahwa pada waktu pemasangan, file APK ini harus diberi izin
ID pengguna yang sama, yaitu identitas runtime, sebagai platform inti. Perhatikan bahwa ini adalah
bergantung pada apk yang ditandatangani dengan sertifikat yang sama dengan platform inti
(lihat LOCAL_CERTIFICATE
di bagian sebelumnya), tetapi keduanya berbeda
konsep:
- beberapa izin atau API dilindungi tanda tangan, yang membutuhkan sertifikat penandatanganan
- beberapa izin atau API memerlukan identitas pengguna
system
dari pemanggil, yang memerlukan paket panggilan untuk membagikan ID pengguna kesystem
, jika berupa paket terpisah dari platform inti itu sendiri
<uses-library android:name="android.test.runner" />
Hal ini diperlukan untuk semua pengujian Instrumentasi karena class terkait dipaketkan dalam file library JAR framework terpisah, sehingga memerlukan entri classpath tambahan saat paket pengujian dipanggil oleh framework aplikasi.
android:targetPackage="android.test.example.helloworld"
Anda mungkin telah memperhatikan bahwa targetPackage
di sini dideklarasikan sama dengan
Atribut package
dideklarasikan dalam tag manifest
file ini. Seperti yang disebutkan dalam
dasar-dasar pengujian, kategori uji instrumentasi ini
yang biasanya ditujukan untuk menguji API framework, jadi ini tidak terlalu berarti
mereka untuk memiliki paket aplikasi
khusus yang ditargetkan, selain itu sendiri.
File konfigurasi sederhana
Setiap modul pengujian baru harus memiliki file konfigurasi untuk mengarahkan sistem build dengan metadata modul, dependensi waktu kompilasi, dan paket petunjuk. Pada umumnya, opsi file {i>Blueprint <i}berbasis Soong memadai. Untuk mengetahui detailnya, lihat Konfigurasi Pengujian Sederhana.
File konfigurasi kompleks
Untuk kasus yang lebih kompleks ini, Anda juga perlu menulis konfigurasi pengujian untuk perangkat uji coba Android, Federasi Perdagangan.
Konfigurasi pengujian dapat menentukan opsi penyiapan perangkat khusus dan setelan default argumen untuk menyediakan class pengujian. Lihat contohnya di /platform_testing/tests/example/instrumentation/AndroidTest.xml.
Snapshot disertakan di sini untuk memudahkan:
<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 tertentu dalam file konfigurasi pengujian:
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="HelloWorldTests.apk"/>
</target_preparer>
Perintah ini memberi tahu Federasi Perdagangan untuk menginstal HelloWorldTests.apk ke target perangkat menggunakan target_preparer yang ditentukan. Ada banyak penyiapan target yang tersedia untuk developer di Trade Federation dan ini dapat digunakan untuk memastikan perangkat disiapkan 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 uji Federasi Perdagangan yang akan digunakan untuk menjalankan pengujian dan meneruskan paket pada perangkat yang akan dieksekusi dan runner pengujian yakni JUnit dalam kasus ini.
Untuk informasi selengkapnya, lihat Konfigurasi Modul Pengujian.
Fitur JUnit4
Dengan menggunakan library android-support-test
sebagai runner pengujian, Anda dapat mengadopsi
Kelas pengujian gaya JUnit4, dan perubahan gerrit sampel berisi beberapa
penggunaan fitur-fiturnya. Lihat contohnya di
/platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java.
Walaupun pola pengujian biasanya hanya untuk tim komponen, ada beberapa pola penggunaan yang umumnya berguna.
@RunWith(JUnit4.class)
public class HelloWorldTest {
Perbedaan yang signifikan di JUnit4 adalah pengujian tidak lagi diperlukan untuk diwarisi dari class pengujian dasar yang umum; sebagai gantinya, Anda menulis pengujian dalam class Java biasa dan menggunakan anotasi untuk menunjukkan penyiapan dan batasan pengujian tertentu. Di beberapa dalam contoh ini, kami menginstruksikan bahwa class 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 oleh JUnit4 untuk melakukan
pembongkaran pra-pengujian dan pasca-pengujian. Demikian pula, @BeforeClass
dan
Anotasi @AfterClass
digunakan pada metode oleh JUnit4 untuk melakukan penyiapan sebelum
mengeksekusi semua pengujian di class pengujian, dan
memutuskan setelahnya. Perhatikan bahwa
pengaturan dan metode pemutusan class-scope harus statis. Untuk metode pengujian,
tidak seperti JUnit versi sebelumnya, keduanya tidak perlu lagi memulai
dengan test
, masing-masing harus dianotasi dengan @Test
. Seperti biasa,
metode pengujian harus bersifat publik, mendeklarasikan tidak ada nilai yang ditampilkan, tidak mengambil parameter, dan
dapat memberikan pengecualian.
Akses class instrumentasi
Meskipun tidak tercakup dalam contoh dasar {i>
hello world<i}, sudah cukup umum bagi
Pengujian Android untuk memerlukan akses instance Instrumentation
: ini adalah API inti
antarmuka yang menyediakan akses ke konteks aplikasi, siklus proses aktivitas
API pengujian terkait dan lainnya.
Karena pengujian JUnit4 tidak lagi memerlukan
class dasar umum, maka
yang diperlukan untuk mendapatkan instance Instrumentation
melalui
InstrumentationTestCase#getInstrumentation()
, sebagai gantinya, runner pengujian baru
mengelolanya melalui InstrumentationRegistry
dengan konfigurasi kontekstual dan lingkungan yang dibuat oleh framework instrumentasi
disimpan.
Untuk mengakses instance class Instrumentation
, cukup panggil metode statis
getInstrumentation()
pada class InstrumentationRegistry
:
Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()
Mem-build dan menguji secara lokal
Untuk kasus penggunaan yang paling umum, gunakan Atest.
Untuk kasus yang lebih kompleks yang memerlukan penyesuaian yang lebih berat, ikuti petunjuk instrumentasi.