Kategori uji instrumentasi ini tidak jauh berbeda dengan yang menargetkan aplikasi Android biasa. Perlu diperhatikan bahwa aplikasi pengujian 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 Persyaratan . Contoh yang dibahas di sini adalah penulisan pengujian instrumentasi baru dengan paket target yang ditetapkan pada paket aplikasi pengujiannya sendiri. Jika Anda tidak terbiasa dengan konsep tersebut, harap baca pengenalan pengujian Platform .
Panduan ini menggunakan tes berikut sebagai contoh:
- kerangka kerja/basis/paket/Shell/tes
Disarankan untuk menelusuri kode terlebih dahulu untuk mendapatkan kesan kasar sebelum melanjutkan.
Memutuskan lokasi sumber
Karena pengujian instrumentasi akan menargetkan aplikasi, konvensinya adalah menempatkan kode sumber pengujian di direktori tests di bawah akar direktori sumber komponen Anda di pohon sumber platform.
Lihat lebih banyak diskusi tentang lokasi sumber dalam contoh end-to-end untuk pengujian instrumentasi mandiri .
File manifes
Sama seperti aplikasi biasa, setiap modul pengujian instrumentasi memerlukan file manifes. Jika Anda menamai file tersebut sebagai AndroidManifest.xml dan memberikannya di samping Android.mk untuk tmodule pengujian Anda, file tersebut akan disertakan secara otomatis oleh file makefile inti BUILD_PACKAGE .
Sebelum melangkah lebih jauh, sangat disarankan untuk membaca Ikhtisar Manifes Aplikasi terlebih dahulu.
Ini memberikan ikhtisar komponen dasar file manifes dan fungsinya.
Versi terbaru file manifes untuk contoh perubahan gerrit dapat diakses di: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml
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 pilihan 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 tersebut.
Karena ini adalah paket aplikasi uji, independen dari paket aplikasi yang diuji, nama paket yang berbeda harus digunakan: satu kesepakatan umum adalah menambahkan akhiran .test .
Selain itu, atribut package ini sama dengan apa yang dikembalikan oleh ComponentName#getPackageName() , dan juga sama yang akan Anda gunakan untuk berinteraksi dengan berbagai sub perintah pm melalui adb shell .
Perlu diketahui 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 dalam aplikasi atau pengujian yang 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 terpisah, oleh karena itu memerlukan entri classpath tambahan saat paket pengujian dipanggil oleh kerangka kerja aplikasi.
android:targetPackage="com.android.shell"
Ini menyetel paket target instrumentasi ke com.android.shell . Saat instrumentasi dipanggil melalui perintah am instrument , framework akan memulai ulang proses com.android.shell , dan memasukkan kode instrumentasi ke dalam proses untuk eksekusi pengujian. 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 bergantung pada kait pengujian yang diekspos.
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. Lihat Konfigurasi Tes Sederhana untuk detailnya.
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 penyiapan perangkat khusus dan argumen default untuk memasok kelas pengujian.
Versi terbaru file konfigurasi untuk contoh perubahan gerrit dapat diakses di: frameworks/base/packages/Shell/tests/AndroidTest.xml
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 pilihan pada file konfigurasi pengujian:
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
Ini memberitahu Trade Federation untuk menginstal ShellTests.apk ke perangkat target menggunakan target_preparer yang ditentukan. Ada banyak pembuat target yang tersedia untuk pengembang di Federasi Dagang dan ini dapat digunakan untuk memastikan perangkat telah diatur dengan benar sebelum pelaksanaan 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 Trade Federation yang akan digunakan untuk menjalankan pengujian dan meneruskan paket pada perangkat yang akan dieksekusi dan kerangka kerja pelari pengujian yang dalam kasus ini adalah JUnit.
Lihat di sini untuk informasi lebih lanjut tentang Test Module Configs
fitur JUnit4
Menggunakan android-support-test library sebagai test runner memungkinkan adopsi kelas pengujian gaya JUnit4 baru, dan contoh perubahan gerrit berisi beberapa penggunaan fitur yang sangat mendasar.
Kode sumber terbaru untuk perubahan gerrit sampel 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 berguna secara umum.
@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
Perbedaan signifikan dalam JUnit4 adalah bahwa pengujian tidak lagi diperlukan untuk mewarisi dari kelas pengujian basis umum; sebagai gantinya, Anda menulis pengujian di kelas Java biasa dan menggunakan anotasi untuk menunjukkan penyiapan dan batasan pengujian tertentu. Dalam contoh ini, kami menginstruksikan bahwa kelas ini harus dijalankan sebagai pengujian Android JUnit4.
Anotasi @SmallTest menetapkan ukuran pengujian untuk seluruh kelas pengujian: semua metode pengujian yang ditambahkan ke dalam kelas pengujian ini mewarisi anotasi ukuran pengujian ini. penyiapan kelas pre test, post test tear down, dan post test class tear down: mirip dengan metode setUp dan tearDown di JUnit4. Anotasi Test digunakan untuk membubuhi keterangan tes yang sebenarnya.
@Before
public void setup() {
...
@Test
public void testGetProvider_shouldCacheProvider() {
...
Anotasi @Before digunakan pada metode oleh JUnit4 untuk melakukan penyiapan pra pengujian. Meskipun tidak digunakan dalam contoh ini, ada juga @After untuk post test teardown. Demikian pula, anotasi @BeforeClass dan @AfterClass dapat digunakan pada metode oleh JUnit4 untuk melakukan penyiapan sebelum menjalankan semua pengujian dalam kelas pengujian, dan pembongkaran setelahnya. Perhatikan bahwa metode penyetelan ruang lingkup kelas dan pembongkaran harus statis.
Untuk metode pengujian, tidak seperti versi JUnit sebelumnya, mereka tidak perlu lagi memulai nama metode dengan test , sebagai gantinya, masing-masing harus dianotasi dengan @Test . Seperti biasa, metode pengujian harus bersifat publik, mendeklarasikan tidak ada nilai kembalian, tidak mengambil parameter, dan dapat melontarkan pengecualian.
Context context = InstrumentationRegistry.getTargetContext();
Karena pengujian JUnit4 tidak lagi memerlukan kelas dasar umum, tidak perlu lagi mendapatkan instance Context melalui getContext() atau getTargetContext() melalui metode kelas dasar; sebagai gantinya, runner pengujian baru mengelolanya melalui InstrumentationRegistry tempat penyiapan kontekstual dan lingkungan yang dibuat oleh kerangka kerja instrumentasi disimpan. Melalui kelas ini, Anda juga dapat menghubungi:
-
getInstrumentation(): instance ke kelasInstrumentation -
getArguments(): argumen baris perintah diteruskan keam instrumentmelalui-e <key> <value>
Bangun dan uji secara lokal
Untuk kasus penggunaan yang paling umum, gunakan Atest .
Untuk kasus yang lebih rumit yang memerlukan penyesuaian lebih berat, ikuti petunjuk instrumentasi .