Google Espresso atau Robotium [ditutup]


116

Saya harus menggunakan alat uji UI Otomatis dan saya bingung antara menggunakan Robotium vs Google Espresso.

Apa perbedaan utama di antara keduanya? Apakah ada fitur yang ada di satu tetapi tidak di yang lain?


20
Sejujurnya saya benci ketika orang memberi suara negatif tanpa menulis komentar apa pun. Saya akan menghargai jika orang yang downvoting menulis beberapa komentar seperti mengapa dia melakukan itu
Androidme

9
Saya rasa pertanyaan itu sangat membantu. Banyak pengembang menanyakan ini pada diri mereka sendiri. Apa perbedaannya? Saya pikir masalahnya adalah cara Anda bertanya. Anda harus menanyakannya lebih detail dan tidak hanya menanyakan mana yang akan digunakan.
tasomaniac

8
Ini adalah pertanyaan tepat yang ingin saya jawab. Terima kasih telah memposting
Richard Fung

8
Saya tidak suka fakta bahwa ini di luar topik menurut StackOverflow. Saya tahu bahwa jika kita harus membandingkan setiap perpustakaan dan alat, mungkin ada banyak jawaban berdasarkan pendapat, tetapi pertanyaan seperti ini yang menanyakan perbedaan antara dua sumber daya sangat membantu.
David Argyle Thacker

Jawaban:


176

Pengungkapan penuh: Saya adalah salah satu penulis Espresso.

Baik Espresso dan Robotium adalah framework berbasis instrumentasi, yang berarti keduanya menggunakan Instrumentasi Android untuk memeriksa dan berinteraksi dengan Aktivitas yang sedang diuji.

Di Google, kami mulai dengan menggunakan Robotium karena lebih nyaman daripada instrumentasi stok (angkat topi kepada pengembang Robotium untuk membuatnya begitu). Namun, itu tidak memenuhi kebutuhan kami akan kerangka kerja yang membuat penulisan tes yang andal menjadi mudah bagi pengembang.

Kemajuan utama dalam Espresso dibandingkan Robotium:

  1. Sinkronisasi. Secara default, logika pengujian instrumentasi dijalankan pada thread (instrumentasi) yang berbeda dengan operasi UI (diproses pada thread UI). Tanpa sinkronisasi operasi pengujian dengan pembaruan UI, pengujian akan rentan terhadap kegagalan - yaitu akan gagal secara acak karena masalah waktu. Sebagian besar penulis pengujian mengabaikan fakta ini, beberapa menambahkan mekanisme sleep / retry dan bahkan lebih sedikit lagi yang menerapkan kode keamanan thread yang lebih canggih. Tak satu pun dari ini yang ideal. Espresso menjaga keamanan thread dengan menyinkronkan tindakan pengujian dan pernyataan dengan UI aplikasi yang sedang diuji secara mulus. Robotium mencoba untuk mengatasinya dengan mekanisme sleep / retry, yang tidak hanya tidak dapat diandalkan, tetapi juga menyebabkan pengujian berjalan lebih lambat dari yang diperlukan.

  2. API. Espresso memiliki API kecil, terdefinisi dengan baik, dan dapat diprediksi, yang terbuka untuk penyesuaian. Anda memberi tahu framework cara menemukan elemen UI menggunakan pencocokan hamcrest standar, lalu menginstruksikannya untuk melakukan tindakan atau memeriksa pernyataan pada elemen target. Anda dapat membandingkan ini dengan API Robotium, di mana penulis pengujian diharapkan untuk memilih dari 30+ metode klik. Selanjutnya, Robotium mengekspos metode berbahaya seperti getCurrentActivity (apa artinya saat ini?) Dan getView, yang memungkinkan Anda untuk beroperasi pada objek di luar utas utama (lihat poin di atas).

  3. Hapus informasi kegagalan. Espresso berusaha memberikan informasi debug yang kaya saat terjadi kegagalan. Selanjutnya, Anda dapat menyesuaikan cara kegagalan ditangani oleh Espresso dengan penangan kegagalan Anda sendiri. Saya belum mencobanya beberapa lama, tetapi versi Robotium sebelumnya mengalami kegagalan penanganan yang tidak konsisten (misalnya metode clickOnView akan menelan SecurityExceptions).

Bertentangan dengan jawaban sebelumnya, Espresso didukung di semua versi API dengan jumlah pengguna yang signifikan (lihat: http://developer.android.com/about/dashboards/index.html ). Ini berfungsi pada beberapa versi yang lebih lama, tetapi mengujinya akan membuang-buang sumber daya. Berbicara tentang pengujian ... Espresso diuji pada setiap perubahan oleh rangkaian pengujian komprehensif (dengan cakupan lebih dari 95%) serta sebagian besar aplikasi android yang dikembangkan oleh Google.


Hai! Terima kasih atas jawaban Anda, Apakah Espresso menawarkan kemungkinan untuk menguji beberapa aplikasi dalam kasus pengujian yang sama? Saya harus menguji aplikasi saya yang memanggil aktivitas dari aplikasi lain (aplikasi saya yang lain yang berbagi sharedUserId yang sama) dan kemudian mengambil hasilnya. Saya tidak bisa melakukan itu dengan Robotium, tapi mungkin dengan Espresso? :-)
nbe_42

1
Tidak - Anda tidak dapat berinteraksi dengan UI di luar proses Anda dengan Espresso. Ini adalah batasan kerangka instrumentasi.
ValeraZakharov

1
@ValeraKharov :: Hai ... !! Seperti yang Anda katakan, espresso akan menangani Sinkronisasi Utas UI dan tidak perlu mengaktifkan mode Tidur. Tetapi dalam kasus saya, saya telah menulis beberapa kasus uji dan semua kasus uji bekerja di mesin lokal saya (Dengan satu tidur per TestSuite sebagai permulaan). Tetapi hampir 99% kasus pengujian gagal ketika saya menjalankan dengan jenkins lokal / server. Saya telah menonaktifkan semua animasi di emulator jenkins. Sebagian besar waktu saya mendapatkan AppNotIdleException. Saya tidak dapat menemukan akar penyebabnya. Bisakah Anda membantu saya.
Naresh Gunda

@Radu Telah melakukannya. Komentar Anda tidak ada dan tanpa penjelasan yang tepat sepertinya merupakan usaha yang bodoh untuk mendapatkan perhatian.
Rakib

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.