Menulis runner pengujian Tradefed

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 yang dipanggil oleh {i> hart<i} saat menggunakan {i>test runner<i}, mirip dengan Java Runnable.

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 ketik ITestInvocationListener. Objek ini adalah kunci untuk pelaporan terstruktur hasil dari runner uji coba ke harness.

Dengan melaporkan hasil terstruktur, runner pengujian memiliki properti berikut:

  • Laporkan daftar yang benar dari semua pengujian yang berjalan, berapa lama waktu yang dibutuhkan, dan apakah mereka lulus secara individual, gagal, atau beberapa status lainnya.
  • Melaporkan 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 di-debug karena ada jejak yang lebih terperinci dari dalam proses eksekusi.

Meskipun demikian, pelaporan hasil terstruktur bersifat opsional; {i>test runner<i} mungkin hanya ingin menilai status seluruh operasi sebagai BERHASIL atau GAGAL tanpa rincian apa pun dari pelaksanaan yang sebenarnya.

Peristiwa berikut dapat dipanggil pada pemroses untuk memberi tahu harness bahwa kemajuan eksekusi saat ini:

  • testRunStarted: Memberi tahu awal tentang sekelompok kasus pengujian yang saling berhubungan.
    • testStarted: Memberi tahu awal kasus pengujian yang dimulai.
    • testFailed/testIgnored: Memberi tahu perubahan status kasus pengujian sedang berlangsung. Kasus pengujian tanpa perubahan status dianggap lulus.
    • testEnded: Memberi tahu akhir kasus pengujian.
  • testRunFailed: Memberi tahu bahwa status keseluruhan grup kasus pengujian maka eksekusinya 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 (untuk alasan: 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 dimaksudkan untuk menjaga agar semuanya mirip dengan sesuatu yang mendasar yang dianggap developer biasanya Anda ketahui.

Melaporkan log dari runner pengujian

Jika Anda menulis class atau runner pengujian Tradefed sendiri, Anda akan mengimplementasikan IRemoteTest dan dapatkan 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 ini:

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

{i>Test runner<i} biasanya tertarik dengan antarmuka ini untuk mendapatkan 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 di beberapa perangkat secara bersamaan. Ini adalah berguna ketika menguji komponen yang memerlukan interaksi eksternal, seperti penyambungan ponsel dan smartwatch.

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

Penyetel dari antarmuka akan selalu dipanggil sebelum metode run, jadi 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 itu adalah bagian darinya dan tempat itu dieksekusi. Lihat objek konfigurasi untuk 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.

Dengan demikian, pemanfaatan dan infrastruktur yang lebih besar dapat memanfaatkan kontrol yang andal 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 disertakan filter diberikan, semua pengujian harus dijalankan selama tidak cocok dengan filter kecualikan.