Google is committed to advancing racial equity for Black communities. See how.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Tulis Test Runner Tradefed

Halaman ini menjelaskan cara menulis runner pengujian baru di Tradefed.

Latar Belakang

Jika Anda penasaran tentang tempat runner pengujian dalam arsitektur Tradefed, lihat Structure of a Test Runner .

Ini bukan prasyarat untuk menulis runner pengujian baru; pelari tes dapat ditulis secara terpisah.

Bare minimum: Menerapkan antarmuka

Minimal untuk memenuhi syarat sebagai runner pengujian 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 itu dianggap sebagai bagian dari eksekusi runner pengujian.

Melaporkan hasil dari test runner

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

Dengan melaporkan hasil terstruktur, runner pengujian memiliki properti berikut:

  • Laporkan daftar yang tepat dari semua pengujian yang berjalan, berapa lama mereka dan jika mereka lulus satu per satu, gagal atau beberapa status lainnya.
  • Laporkan metrik yang terkait dengan pengujian jika berlaku, misalnya metrik waktu penginstalan.
  • Cocok di sebagian besar perkakas infrastruktur, misalnya hasil tampilan dan metrik, dll.
  • Biasanya lebih mudah untuk men-debug karena ada jejak eksekusi yang lebih terperinci.

Oleh karena itu, melaporkan hasil terstruktur bersifat opsional; runner pengujian mungkin hanya ingin menilai status keseluruhan proses sebagai LULUS atau GAGAL tanpa detail apa pun dari eksekusi sebenarnya.

CATATAN: Lebih sulit untuk menerapkan pelari yang mengikuti urutan kejadian, tetapi kami menyarankan melakukannya dengan mempertimbangkan manfaat yang tercantum di atas.

Peristiwa berikut dapat dipanggil di listener untuk memberi tahu harness tentang kemajuan eksekusi saat ini:

  • testRunStarted: Memberi tahu awal dari grup kasus pengujian yang terkait bersama.
    • testStarted: Memberi tahu permulaan kasus uji yang dimulai.
    • testFailed / testIgnored: Beri tahu perubahan status kasus uji yang sedang berlangsung. Kasus uji tanpa perubahan status dianggap lulus.
    • testEnded: Beri tahu akhir kasus uji.
  • testRunFailed: Beri tahu bahwa status keseluruhan grup eksekusi kasus uji gagal. Sebuah uji coba bisa lulus atau gagal secara independen dari hasil kasus uji tergantung pada apa yang diharapkan eksekusi. Misalnya, biner yang menjalankan beberapa kasus uji dapat melaporkan semua kasus uji lulus tetapi dengan kode keluar kesalahan (karena alasan apa pun: file bocor, dll.).
  • testRunEnded: Memberi tahu akhir dari grup kasus pengujian.

Mempertahankan dan memastikan urutan callback yang benar adalah tanggung jawab pelaksana runner pengujian, misalnya memastikan bahwa testRunEnded dipanggil jika terjadi pengecualian menggunakan klausa finally .

Callback kasus pengujian ( testStarted , testEnded , dll.) testEnded 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 agar hal-hal tetap dekat dengan sesuatu yang mendasar yang biasanya diketahui oleh pengembang.

Melaporkan log dari runner pengujian

Jika Anda membuat runner atau kelas 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 ITestDevice yang mewakili perangkat yang sedang diuji dan menyediakan API untuk berinteraksi dengannya.
  • IBuildReceiver memungkinkan pengujian untuk mendapatkan objek IBuildInfo dibuat pada langkah penyedia build yang berisi semua informasi dan artefak yang terkait dengan penyiapan pengujian.

Pelari pengujian biasanya tertarik dengan antarmuka ini untuk mendapatkan artefak yang terkait dengan eksekusi, misalnya file tambahan, dan membuat perangkat dalam pengujian yang akan ditargetkan selama eksekusi.

Menguji dengan banyak perangkat

Tradefed mendukung menjalankan pengujian pada beberapa perangkat secara bersamaan. Ini berguna saat menguji komponen yang memerlukan interaksi eksternal, seperti ponsel dan penyandingan jam tangan.

Untuk menulis runner pengujian 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 terkait.

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

Tes mengetahui pengaturan mereka

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 dijalankan sebelumnya, dll.

Untuk mencapai hal ini, runner pengujian dapat mengakses objek IConfiguration yang merupakan bagiannya dan yang dieksekusi. Lihat deskripsi objek konfigurasi untuk lebih jelasnya.

Untuk implementasi test runner, Anda perlu mengimplementasikan IConfigurationReceiver untuk menerima objek IConfiguration .

Pelari tes yang fleksibel

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

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

Dukungan penyaringan dijelaskan dalam antarmuka ITestFilterReceiver , yang memungkinkan untuk menerima set include dan exclude filter untuk tes yang harus atau tidak harus dijalankan.

Ketentuan kami adalah bahwa pengujian akan dijalankan IFF jika 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 filter pengecualian mana pun.

CATATAN: Kami menganjurkan agar pelari pengujian ditulis dengan cara yang mendukung pemfilteran ini karena memberikan nilai tambah yang sangat besar dalam infrastruktur yang lebih besar. Namun kami memahami bahwa dalam beberapa kasus hal itu tidak mungkin dilakukan.