Halaman ini menjelaskan cara menulis test runner baru di Tradefed.
Latar belakang
Jika Anda penasaran tentang tempat test runner dalam arsitektur Tradefed, lihat Structure of a Test Runner .
Ini bukan prasyarat untuk menulis test runner baru; pelari tes dapat ditulis secara terpisah.
Minimal: Implementasikan antarmuka
Persyaratan minimum untuk memenuhi syarat sebagai test runner Tradefed adalah dengan mengimplementasikan antarmuka IRemoteTest dan lebih khusus lagi metode run(TestInformation testInfo, ITestInvocationListener listener) .
Metode ini adalah metode yang dipanggil oleh harness saat menggunakan test runner, mirip dengan Java Runnable.
Setiap bagian dari metode tersebut dianggap sebagai bagian dari eksekusi test runner.
Laporkan hasil dari pelari tes
Metode run di antarmuka dasar memberikan akses ke objek pendengar bertipe ITestInvocationListener . Objek ini adalah kunci untuk melaporkan hasil terstruktur dari test runner ke harness.
Dengan melaporkan hasil terstruktur, test runner memiliki properti berikut:
- Laporkan daftar yang tepat dari semua tes yang dijalankan, berapa lama waktu yang dibutuhkan dan apakah tes tersebut lulus, gagal, atau kondisi lainnya.
- Laporkan metrik yang terkait dengan pengujian jika berlaku, misalnya metrik waktu instalasi.
- Cocok untuk sebagian besar peralatan infrastruktur, misalnya menampilkan hasil dan metrik, dll.
- Biasanya lebih mudah untuk di-debug karena ada jejak eksekusi yang lebih terperinci.
Meskipun demikian, melaporkan hasil terstruktur bersifat opsional; seorang pelari pengujian mungkin hanya ingin menilai status keseluruhan proses sebagai LULUS atau GAGAL tanpa rincian eksekusi sebenarnya.
Peristiwa berikut dapat dipanggil ke pendengar untuk memberi tahu harness tentang kemajuan eksekusi saat ini:
- testRunStarted: Memberi tahu permulaan sekelompok kasus uji yang terkait bersama.
- testStarted: Memberi tahu awal dimulainya kasus uji.
- testFailed/testIgnored: Memberi tahu perubahan status kasus uji yang sedang berlangsung. Kasus uji tanpa adanya perubahan status dianggap lulus.
- testEnded: Beritahukan akhir kasus uji.
- testRunFailed: Beritahukan bahwa status keseluruhan grup eksekusi kasus uji adalah kegagalan. Uji coba dapat lulus atau gagal , terlepas dari hasil kasus pengujian, bergantung pada apa yang diharapkan dari eksekusi. Misalnya, biner yang menjalankan beberapa kasus pengujian dapat melaporkan semua kasus pengujian yang lulus tetapi dengan kode keluar kesalahan (karena alasan apa pun: file bocor, dll.).
- testRunEnded: Memberi tahu akhir dari grup kasus uji.
Mempertahankan dan memastikan urutan callback yang benar adalah tanggung jawab pelaksana test runner, misalnya memastikan bahwa testRunEnded dipanggil jika terjadi pengecualian menggunakan klausa finally .
Callback kasus uji ( testStarted , testEnded , dll.) bersifat opsional. Uji coba mungkin terjadi tanpa kasus uji apa pun.
Anda mungkin memperhatikan bahwa struktur peristiwa ini terinspirasi dari struktur khas JUnit . Hal ini bertujuan untuk menjaga segala sesuatunya tetap dekat dengan sesuatu yang mendasar yang biasanya diketahui oleh pengembang.
Laporkan log dari test runner
Jika Anda menulis kelas pengujian atau runner Tradefed Anda sendiri, Anda akan mengimplementasikan IRemoteTest dan mendapatkan ITestInvocationListener melalui metode run() . Listener ini dapat digunakan untuk mencatat file sebagai berikut:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Uji dengan perangkat
Antarmuka minimum di atas memungkinkan untuk menjalankan pengujian yang sangat sederhana yang terisolasi dan tidak memerlukan sumber daya tertentu, misalnya pengujian unit Java.
Penulis pengujian yang ingin melanjutkan ke langkah pengujian perangkat berikutnya memerlukan antarmuka berikut:
- IDeviceTest memungkinkan untuk menerima objek
ITestDeviceyang mewakili perangkat yang diuji dan menyediakan API untuk berinteraksi dengannya. - IBuildReceiver memungkinkan pengujian untuk membuat objek
IBuildInfodibuat pada langkah penyedia build yang berisi semua informasi dan artefak yang terkait dengan pengaturan pengujian.
Pelari pengujian biasanya tertarik dengan antarmuka ini untuk mendapatkan artefak yang terkait dengan eksekusi, misalnya file tambahan, dan mendapatkan perangkat yang diuji yang akan ditargetkan selama eksekusi.
Uji dengan beberapa perangkat
Tradefed mendukung pengujian yang dijalankan pada beberapa perangkat secara bersamaan. Ini berguna saat menguji komponen yang memerlukan interaksi eksternal, seperti penyandingan ponsel dan jam tangan.
Untuk menulis test runner yang dapat menggunakan beberapa perangkat, Anda perlu mengimplementasikan IMultiDeviceTest , yang memungkinkan menerima peta ITestDevice ke IBuildInfo yang berisi daftar lengkap representasi perangkat dan informasi build terkait.
Penyetel dari antarmuka akan selalu dipanggil sebelum metode run , jadi dapat diasumsikan bahwa struktur akan tersedia saat run dipanggil.
Pengujian mengetahui pengaturannya
Beberapa implementasi test runner mungkin memerlukan informasi tentang keseluruhan penyiapan agar dapat berfungsi dengan baik, misalnya beberapa metadata tentang pemanggilan, atau target_preparer mana yang dijalankan sebelumnya, dll.
Untuk mencapai hal ini, test runner dapat mengakses objek IConfiguration yang menjadi bagiannya dan tempat eksekusinya. Lihat deskripsi objek konfigurasi untuk detail selengkapnya.
Untuk implementasi test runner, Anda perlu mengimplementasikan IConfigurationReceiver untuk menerima objek IConfiguration .
Pelari tes yang fleksibel
Pelari pengujian dapat memberikan cara yang fleksibel dalam menjalankan pengujian jika mereka memiliki kontrol yang terperinci terhadap pengujian tersebut, misalnya pelari pengujian JUnit dapat menjalankan setiap pengujian unit secara individual.
Hal ini memungkinkan harness dan infrastruktur yang lebih besar untuk memanfaatkan kontrol yang baik tersebut dan pengguna untuk menjalankan sebagian test runner 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 bahwa pengujian akan dijalankan JIKA cocok dengan satu atau lebih filter penyertaan DAN tidak cocok dengan filter pengecualian mana pun. Jika tidak ada filter penyertaan yang diberikan, semua pengujian harus dijalankan selama tidak cocok dengan filter pengecualian mana pun.