Menulis runner pengujian Tradefed

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Halaman ini menjelaskan cara menulis runner pengujian baru di Tradefed.

Latar belakang

Jika Anda ingin tahu tentang tempat {i> test runner<i} dalam arsitektur Tradefed, lihat Struktur Test Runner.

Ini bukan prasyarat untuk menulis runner pengujian baru; {i>test runner<i} bisa yang ditulis secara terpisah.

Minimum: Mengimplementasikan antarmuka

Persyaratan minimum untuk memenuhi syarat sebagai runner pengujian Tradefed adalah menerapkan Antarmuka IRemoteTest dan lebih khusus lagi 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 pelaporan terstruktur hasil dari runner uji coba 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 peralatan 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; {i>test runner<i} mungkin hanya ingin menilai status seluruh proses sebagai BERHASIL atau GAGAL tanpa rincian apa pun dari pelaksanaan 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 yang 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 adalah kegagalan. Pengujian bisa berupa lulus atau gagal secara terpisah dari hasil kasus uji, bergantung pada yang diharapkan oleh eksekusi. 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.

Memelihara dan memastikan urutan callback yang benar adalah tanggung jawab implementasi {i> test runner<i}, misalnya memastikan bahwa testRunEnded dipanggil jika terjadi pengecualian menggunakan klausa finally.

Callback kasus pengujian (testStarted, testEnded, dll.) bersifat opsional. Sebuah tes dapat berjalan tanpa adanya kasus pengujian.

Anda mungkin memperhatikan 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 sangat sederhana yang diisolasi dan tidak memerlukan resource tertentu, misalnya pengujian unit Java.

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

• IDeviceTest memungkinkan untuk menerima objek ITestDevice yang mewakili perangkat yang sedang diuji dan menyediakan API untuk berinteraksi dengannya.
• IBuildReceiver memungkinkan pengujian untuk 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 mengetahui penyiapannya

Beberapa implementasi runner pengujian mungkin memerlukan informasi tentang penyiapan keseluruhan agar 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 bagian dari dan tempatnya dieksekusi. Lihat deskripsi objek konfigurasi untuk mengetahui detail selengkapnya.

Untuk implementasi runner pengujian, Anda perlu menerapkan IConfigurationReceiver untuk menerima objek IConfiguration.

Runner pengujian fleksibel

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

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 di Antarmuka ITestFilterReceiver, yang memungkinkan untuk menerima kumpulan filter include dan exclude untuk pengujian yang boleh atau tidak boleh berjalan.

Konvensi kami adalah bahwa tes akan dijalankan IFF yang cocok dengan satu atau beberapa filter sertakan DAN tidak cocok dengan filter kecualikan mana pun. Jika tidak ada filter sertakan yang diberikan, semua pengujian harus dijalankan selama tidak cocok dengan filter kecualikan.