Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Menulis runner pengujian Tradefed

Halaman ini menjelaskan cara menulis runner pengujian baru di Tradefed.

Latar belakang

Jika Anda ingin mengetahui tempat runner pengujian dalam arsitektur Tradefed, lihat Struktur Runner Pengujian.

Hal ini bukan prasyarat untuk menulis runner pengujian baru; runner pengujian dapat ditulis secara terpisah.

Minimum: Mengimplementasikan antarmuka

Persyaratan minimum untuk memenuhi syarat sebagai runner pengujian Tradefed adalah menerapkan antarmuka IRemoteTest dan lebih khusus metode run(TestInformation testInfo, ITestInvocationListener listener).

Metode ini adalah metode yang dipanggil oleh harness saat menggunakan runner pengujian, serupa dengan Runnable Java.

Setiap bagian dari metode tersebut dianggap sebagai bagian dari eksekusi runner pengujian.

Melaporkan hasil dari runner pengujian

Metode run di antarmuka dasar memberikan akses ke objek pemroses berjenis ITestInvocationListener. Objek ini adalah kunci untuk melaporkan hasil terstruktur dari runner pengujian ke harness.

Dengan melaporkan hasil terstruktur, runner pengujian memiliki properti berikut:

Melaporkan daftar yang tepat dari semua pengujian yang dijalankan, berapa lama waktu yang diperlukan, dan apakah pengujian tersebut lulus, gagal, atau status lainnya.
Laporkan metrik yang terkait dengan pengujian jika berlaku, misalnya metrik waktu penginstalan.
Sesuai dengan sebagian besar alat infrastruktur, misalnya menampilkan hasil dan metrik, dll.
Biasanya lebih mudah untuk di-debug karena ada rekaman aktivitas eksekusi yang lebih terperinci.

Meskipun demikian, pelaporan hasil terstruktur bersifat opsional; runner pengujian mungkin hanya ingin menilai status seluruh operasi sebagai LULUS atau GAGAL tanpa detail eksekusi yang sebenarnya.

Peristiwa berikut dapat dipanggil di pemroses untuk memberi tahu harness tentang progres eksekusi saat ini:

testRunStarted: Memberi tahu awal grup kasus pengujian yang terkait.
- testStarted: Memberi tahu awal kasus pengujian dimulai.
- testFailed/testIgnored: Memberi tahu perubahan status kasus pengujian yang sedang berlangsung. Kasus pengujian tanpa perubahan status apa pun dianggap lulus.
- testEnded: Memberi tahu akhir kasus pengujian.
testRunFailed: Memberi tahu bahwa status keseluruhan grup eksekusi kasus pengujian gagal. Pengujian yang dijalankan dapat berupa lulus atau gagal terlepas dari hasil kasus pengujian, bergantung pada eksekusi yang diharapkan. Misalnya, biner yang menjalankan beberapa kasus pengujian dapat melaporkan semua kasus pengujian lulus, tetapi dengan kode keluar error (karena alasan apa pun: file yang bocor, dll.).
testRunEnded: Memberi tahu akhir grup kasus pengujian.

Menjaga dan memastikan urutan callback yang tepat adalah tanggung jawab pengimplementasi runner pengujian, misalnya memastikan bahwa testRunEnded dipanggil jika terjadi pengecualian menggunakan klausa finally.

Callback kasus pengujian (testStarted, testEnded, dll.) bersifat opsional. Pengujian mungkin terjadi tanpa kasus pengujian apa pun.

Anda mungkin melihat bahwa struktur peristiwa ini terinspirasi dari struktur JUnit standar. Hal ini sengaja dilakukan agar tetap dekat dengan hal-hal dasar yang biasanya diketahui developer.

Melaporkan log dari runner pengujian

Jika menulis class atau runner pengujian Tradefed Anda sendiri, Anda akan menerapkan IRemoteTest dan mendapatkan ITestInvocationListener melalui metode run(). Pemroses ini dapat digunakan untuk mencatat file sebagai berikut:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Menguji dengan perangkat

Antarmuka minimum di atas memungkinkan pengujian yang sangat sederhana dijalankan secara terpisah dan tidak memerlukan resource tertentu, misalnya pengujian unit Java.

Penulis pengujian yang ingin melanjutkan ke langkah berikutnya dalam pengujian perangkat akan memerlukan antarmuka berikut:

IDeviceTest memungkinkan untuk menerima objek ITestDevice yang mewakili perangkat yang sedang diuji dan menyediakan API untuk berinteraksi dengannya.
IBuildReceiver memungkinkan pengujian mendapatkan objek IBuildInfo yang dibuat pada langkah penyedia build yang berisi semua informasi dan artefak yang terkait dengan penyiapan pengujian.

Runner pengujian biasanya tertarik dengan antarmuka ini untuk mendapatkan artefak yang terkait dengan eksekusi, misalnya file tambahan, dan mendapatkan perangkat yang sedang diuji yang akan ditargetkan selama eksekusi.

Menguji dengan beberapa perangkat

Tradefed mendukung pengujian yang berjalan di beberapa perangkat secara bersamaan. Hal ini berguna saat menguji komponen yang memerlukan interaksi eksternal, seperti penyambungan ponsel dan smartwatch.

Untuk menulis runner pengujian yang dapat menggunakan beberapa perangkat, Anda harus menerapkan IMultiDeviceTest, yang akan memungkinkan untuk menerima peta ITestDevice ke IBuildInfo yang berisi daftar lengkap representasi perangkat dan informasi build terkait.

Penyetel dari antarmuka akan selalu dipanggil sebelum metode run, sehingga aman untuk mengasumsikan bahwa struktur akan tersedia saat run dipanggil.

Pengujian yang mengetahui penyiapannya

Beberapa implementasi runner pengujian mungkin memerlukan informasi tentang penyiapan secara keseluruhan agar dapat berfungsi dengan benar, misalnya beberapa metadata tentang pemanggilan, atau target_preparer yang dijalankan sebelumnya, dll.

Untuk mencapai hal ini, runner pengujian dapat mengakses objek IConfiguration yang menjadi bagiannya dan tempatnya dieksekusi. Lihat deskripsi objek konfigurasi untuk mengetahui detail selengkapnya.

Untuk penerapan runner pengujian, Anda harus menerapkan IConfigurationReceiver untuk menerima objek IConfiguration.

Runner pengujian fleksibel

Runner pengujian dapat memberikan cara yang fleksibel untuk menjalankan pengujian jika memiliki kontrol terperinci atas pengujian tersebut, misalnya runner pengujian JUnit dapat menjalankan setiap pengujian unit secara terpisah.

Hal ini memungkinkan harness dan infrastruktur yang lebih besar memanfaatkan kontrol yang baik tersebut dan pengguna untuk menjalankan sebagian runner pengujian melalui pemfilteran.

Dukungan pemfilteran dijelaskan dalam antarmuka ITestFilterReceiver, yang memungkinkan untuk menerima kumpulan filter include dan exclude untuk pengujian yang harus atau tidak boleh dijalankan.

Konvensi kami adalah pengujian akan dijalankan JIKA cocok dengan satu atau beberapa filter yang disertakan DAN tidak cocok dengan filter yang dikecualikan. Jika tidak ada filter sertakan yang diberikan, semua pengujian harus dijalankan selama tidak cocok dengan filter kecualikan.