Artikel ini diterbitkan atas nama Andrey Ivanov dan Ekaterina Bateeva , neifmetus
Otomasi aplikasi seluler adalah bidang yang agak muda: ada banyak kerangka kerja dan banyak proyek dihadapkan dengan masalah memilih yang paling "cepat, stabil, mudah digunakan". Sekitar dua tahun lalu, kami juga dihadapkan pada pilihan alat otomatisasi baru untuk menguji aplikasi Android.
Semua alat populer entah bagaimana didasarkan pada UIAutomator dan Espresso, jadi kami memutuskan untuk mengujinya dalam bentuk murni dan membandingkannya dengan Appium yang sama (yang paling populer) dan
seeTest (digunakan sebelumnya, yang terbaik di antara yang berbayar pada waktu itu).
Dari kelebihan Appium, seseorang dapat membedakan API WebDriver yang biasa, kemampuan untuk menggunakan bahasa dan pustaka yang paling populer. Selain itu, ini banyak digunakan di banyak perusahaan dan memungkinkan Anda untuk menulis tes langsung untuk platform iOS dan Android. Dan akhirnya, ini adalah solusi kotak gratis - apa yang bisa lebih baik?
Jadi kami berpikir, sampai kami menemukan kekurangan berikut:
- stabilitas rendah Appium Server
- Anda tidak dapat berinteraksi dengan metode publik untuk Kegiatan (pada 2018, Nikolai Abalov dari Badoo berbicara tentang membuat pintu belakang di Appium dalam artikelnya, Anda dapat membaca di sini )
- sangat rendah dalam kecepatan tes Espresso
Bagi kami, momen-momen ini sangat penting, sehingga diputuskan untuk mengumpulkan seperangkat alat kami sendiri di sekitar Espresso untuk membangun ekosistem untuk menguji aplikasi seluler.
Jadi, kerangka kerja dipilih, tetap mencari komponen yang tersisa:
- Pelari - harus memungkinkan untuk menjalankan tes secara paralel dan mengonfigurasi kumpulan perangkat
- Reporter - harus memberikan laporan yang dapat dibaca yang dapat digunakan oleh anggota tim mana pun
Alat-alatnya
Semuanya baik-baik saja dengan pelari, mencari-cari sedikit di github,
shazam / garpu dipilih.
Ini memungkinkan Anda untuk dengan mudah mengkonfigurasi kumpulan perangkat, mudah dimodifikasi, menghasilkan laporan html sederhana. Logcat diterapkan untuk setiap laporan, jika terjadi uji stacktrace dan kerusakan video. Rekaman video tidak berfungsi dengan benar, semua video berdurasi 1 menit, terkadang beberapa tes direkam pada video.
Laporan garpu jauh dari ideal, pengguna akhir tidak mengerti apa yang sedang terjadi dalam pengujian hanya dengan namanya, tanpa harus membawa test case. Saya ingin memiliki langkah-langkah dengan lampiran file yang memungkinkan saya untuk menyusun laporan. Pencarian reporter untuk tes instrumentasi menghasilkan 2 varian sendok dan mentimun. Kedua opsi tersebut dibuang karena banyak tangkapan layar dalam kasus sendok dan bdd dari mentimun tidak menyelesaikan masalah sepenuhnya ...
Allure sepertinya solusi paling optimal untuk masalah ini:
- bersarang langkah-langkah yang memungkinkan Anda untuk menyusun laporan
- kemampuan untuk merekam data pengujian khusus (tangkapan layar, video, nomor tugas, parameter pengujian)
- tampilan laporan yang ringkas
Tapi ada satu peringatan, Allure tidak dimulai di Android.
Allure-android
Sehubungan dengan hal di atas, diputuskan untuk menulis perpustakaan yang menggabungkan kesederhanaan dan keanggunan Kotlin, keuntungan dari kerangka kerja Allure dan dapat bekerja pada ponsel Android. Untuk menghubungkan perpustakaan, tambahkan dependensi ke modul tempat tes instrumentasi berada:
dependencies { androidTestImplementation "ru.tinkoff.allure:allure-android:$allureVersion@aar" androidTestImplementation "ru.tinkoff.allure:allure-common:$allureVersion" androidTestImplementation "ru.tinkoff.allure:allure-model:$allureVersion" }
Setelah mengatur dependensi, kita perlu mendaftarkan
AllureRunListener ke kelas yang bertanggung jawab untuk menjalankan tes android.
Ada tiga cara untuk melakukan ini:
- Tambahkan ke build.gradle
testInstrumentationRunner "ru.tinkoff.allure.android.AllureAndroidRunner"
- Tambahkan pendengar ke argumen di Runner onCreate (argumen: Bundle)
arguments.putCharSequence("listener", AllureAndroidListener::class.java.name)
- Langsung diwarisi dari AllureAndroidRunner
Laporan daya pikat didasarkan pada langkah - langkah, aksi atom yang dilakukan selama pengujian. Penjelasan Allure
Step dan
Parameter framework telah diganti dengan panggilan langsung ke fungsi step ().
inline fun <T : Any?> step(description: String, vararg params: Parameter, block: () -> T): T
Fungsi ini tidak hanya menggantikan dua anotasi sekaligus, tetapi juga menerima lambda di mana Anda harus membungkus tes logika. Sebagai contoh:
Setelah memulai tes, laporan dalam format json yang disiapkan untuk Allure2 akan muncul di ponsel di folder / sdcard / allure-results. Setelah mengeluarkan hasilnya, tim
adb pull /sdcard/allure-results
kami dapat menghasilkan laporan
allure generate
Dari fitur tambahan, kita dapat membedakan:
- kemampuan untuk menginvestasikan langkah satu sama lain
- di mana saja, Anda dapat memanggil deviceScreenshot (tag: String) untuk mengambil tangkapan layar yang akan secara otomatis dilampirkan ke laporan pada langkah saat ini
- FailshotRule () - junit4 Rule, akan mengambil tangkapan layar sesaat sebelum musim gugur
Ini adalah ikhtisar tentang penggunaan Allure di platform Android. Solusi allure-android tersedia di
GitHub , Anda dapat melihat secara detail dan berpartisipasi dalam pengembangan.