Halaman ini menjelaskan cara menulis test runner baru di Tradefed.
Latar belakang
Jika Anda ingin tahu tentang tempat test runner dalam arsitektur Tradefed, lihat Struktur Test Runner .
Ini bukan prasyarat untuk menulis test runner baru; pelari uji dapat ditulis secara terpisah.
Minimal: Menerapkan antarmuka
Minimal untuk memenuhi syarat sebagai test runner Tradefed adalah mengimplementasikan antarmuka IRemoteTest dan lebih khusus lagi metode run(TestInformation testInfo, ITestInvocationListener listener) .
Metode ini adalah yang dipanggil oleh harness saat menggunakan test runner, mirip dengan Java Runnable.
Setiap bagian dari metode itu dianggap sebagai bagian dari eksekusi test runner.
Melaporkan hasil dari pelari uji
Metode run di antarmuka dasar memberikan akses ke objek listener 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 berjalan, berapa lama waktu yang dibutuhkan dan jika mereka lulus satu per satu, gagal, atau beberapa status lainnya.
- Laporkan metrik yang terkait dengan pengujian jika berlaku, misalnya metrik waktu pemasangan.
- Cocok di sebagian besar perkakas infrastruktur, misalnya hasil tampilan dan metrik, dll.
- Biasanya lebih mudah untuk di-debug karena ada jejak eksekusi yang lebih terperinci.
Yang mengatakan, melaporkan hasil terstruktur adalah opsional; pelari uji mungkin hanya ingin menilai status keseluruhan proses sebagai LULUS atau GAGAL tanpa detail eksekusi yang sebenarnya.
CATATAN: Lebih sulit untuk menerapkan pelari yang mengikuti urutan acara, tetapi kami merekomendasikan melakukannya mengingat manfaat yang tercantum di atas.
Peristiwa berikut dapat dipanggil pada pendengar untuk memberi tahu harness tentang kemajuan eksekusi saat ini:
- testRunStarted: Memberi tahu awal sekelompok kasus uji yang terkait bersama.
- testStarted: Memberi tahu awal kasus uji dimulai.
- testFailed/testIgnored: Memberi tahu perubahan status kasus uji yang sedang berlangsung. Kasus uji tanpa perubahan status dianggap lulus.
- testEnded: Memberi tahu akhir kasus uji.
- testRunFailed: Memberi tahu bahwa status keseluruhan grup eksekusi kasus uji gagal. Uji coba dapat lulus atau gagal secara independen dari hasil kasus uji tergantung pada apa yang diharapkan oleh eksekusi. Misalnya, biner yang menjalankan beberapa kasus uji dapat melaporkan semua kasus uji yang lulus tetapi dengan kode keluar kesalahan (untuk alasan apa pun: file bocor, dll.).
- testRunEnded: Memberi tahu akhir grup kasus uji.
Mempertahankan dan memastikan urutan callback yang tepat adalah tanggung jawab pelaksana runner pengujian, 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 acara ini terinspirasi dari struktur JUnit yang khas . Ini bertujuan untuk menjaga hal-hal tetap dekat dengan sesuatu yang mendasar yang biasanya diketahui oleh pengembang.
Melaporkan log dari pelari uji
Jika Anda menulis kelas atau runner pengujian 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);
Menguji 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 akan memerlukan antarmuka berikut:
- IDeviceTest memungkinkan untuk menerima objek
ITestDeviceyang mewakili perangkat yang diuji dan menyediakan API untuk berinteraksi dengannya. - IBuildReceiver memungkinkan pengujian untuk mendapatkan objek
IBuildInfoyang dibuat pada langkah penyedia build yang berisi semua informasi dan artefak yang terkait dengan penyiapan pengujian.
Pelari uji biasanya tertarik pada antarmuka ini untuk mendapatkan artefak yang terkait dengan eksekusi, misalnya file tambahan, dan mendapatkan perangkat yang diuji yang akan ditargetkan selama eksekusi.
Pengujian dengan beberapa perangkat
Tradefed mendukung pengujian yang berjalan pada beberapa perangkat secara bersamaan. Ini berguna saat menguji komponen yang memerlukan interaksi eksternal, seperti ponsel dan jam tangan yang dipasangkan.
Untuk menulis test runner yang dapat menggunakan beberapa perangkat, Anda perlu mengimplementasikan IMultiDeviceTest , yang akan memungkinkan untuk menerima peta ITestDevice ke IBuildInfo yang berisi daftar lengkap representasi perangkat dan informasi build terkaitnya.
Setter dari antarmuka akan selalu dipanggil sebelum metode run , jadi aman untuk mengasumsikan bahwa struktur akan tersedia saat run dipanggil.
Tes menyadari pengaturannya
CATATAN: Ini bukan kasus penggunaan yang sangat umum. Ini didokumentasikan untuk kelengkapan, tetapi Anda biasanya tidak membutuhkannya.
Beberapa implementasi test runner mungkin memerlukan informasi tentang keseluruhan penyiapan agar berfungsi dengan baik, misalnya beberapa metadata tentang pemanggilan, atau target_preparer mana yang dijalankan sebelumnya, dll.
Untuk mencapai ini, pelari uji 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 uji fleksibel
Test runner dapat memberikan cara yang fleksibel untuk menjalankan pengujian jika mereka memiliki kontrol granular atas pengujian tersebut, misalnya runner pengujian JUnit dapat menjalankan setiap unit test secara individual.
Hal ini memungkinkan harness dan infrastruktur yang lebih besar untuk memanfaatkan kontrol yang baik itu dan pengguna untuk menjalankan sebagian test runner melalui pemfilteran .
Dukungan pemfilteran dijelaskan dalam antarmuka ITestFilterReceiver , yang memungkinkan untuk menerima set filter yang include dan exclude disertakan untuk pengujian yang harus atau tidak harus dijalankan.
Konvensi kami adalah bahwa pengujian akan dijalankan IFF cocok dengan satu atau beberapa 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 salah satu filter pengecualian.
CATATAN: Kami mendorong runner pengujian untuk ditulis dengan cara yang mendukung pemfilteran ini karena memberikan nilai tambah yang sangat besar dalam infrastruktur yang lebih besar. Tetapi kami memahami bahwa dalam beberapa kasus tidak mungkin untuk melakukannya.