Sedikit lebih dari setahun yang lalu, saya pertama kali mencoba Kerangka Robot. Selama partisipasi saya dalam proyek berskala besar, saya mengalami dua pendekatan berbeda untuk menguji otomatisasi dengan alat ini: menulis tes pada Kerangka Robot DSL murni dan bekerja bersama dengan Python. Jika jalur pertama memiliki ambang masuk yang rendah, maka jalur kedua, menurut saya, lebih nyaman dari sudut pandang mendukung proyek-proyek besar. Meskipun tidak ada perbedaan mendasar antara pendekatan. Dengan satu atau lain cara, semuanya bermuara pada menemukan perpustakaan.
Namun, ada baiknya berbicara tentang fitur pendekatan.
Siapa itu Robot dan apa yang dimakannya
Mungkin layak dimulai dengan pengenalan alat yang ampuh ini.
Kerangka Robot adalah kerangka kerja untuk pengujian berbasis kata kunci. Ini digunakan untuk mengotomatisasi pengujian penerimaan dan ATDD (pendekatan pengembangan melalui pengujian penerimaan). Sistem ini memiliki sintaksis data uji yang mudah digunakan dan memungkinkan Anda mengotomatiskan pengujian menggunakan kata kunci. Selain itu, Kerangka Robot memiliki pustaka built-in dan pihak ketiga yang sangat baik yang memungkinkan Anda untuk dengan cepat memulai dan mengintegrasikan otomatisasi ke dalam proses kerja tanpa menemukan sepeda Anda sendiri - ambang masuk yang sama dengan yang saya sebutkan di atas.
Struktur dasar Kerangka Robot diimplementasikan menggunakan Python dan juga berfungsi pada Jython (JVM) dan IronPython (.NET).
Contoh penggunaan, serta dokumentasi lengkap tentang kerangka kerja dan perpustakaan internal dapat ditemukan di situs web resmi proyek:
http://robotframework.org/ .
Langkah pertama saya. Pendekatan pertama
Untuk pertama kalinya, saya menemukan Robot Framework setahun yang lalu, setelah mengubah pekerjaan saya. Sebelum itu, saya hanya otomatis di Java dan C #.
Memilih sendiri alat yang harus saya gunakan untuk tes yang ada, saya mewawancarai kolega baru tentang preferensi mereka. Mereka tidak menyetujui IDE terbaik untuk bekerja dengan Kerangka Robot. Plugin untuk berbagai editor teks dan IDE, seperti PyCharm, terutama memungkinkan bekerja dengan Kerangka Robot. Dan rekomendasi yang saya kumpulkan dibagi 50/50 antara Atom dan PyCharm. Tentu saja, ada NAIK, tetapi ini bukan obat mujarab. Pada waktu itu (setahun yang lalu), saya tidak menemukan dokumentasi yang normal di atasnya, dan dalam yang saya temukan, saya tidak melihat nilai tambah yang besar untuk tugas saya. Karena itu, sebagai permulaan, saya memutuskan untuk mencoba Atom dengan plugin. Mengkloning repositori, saya mulai perlahan mempelajari apa yang terjadi dalam pengujian kami dan dalam Kerangka Robot itu sendiri.
Saya telah terhubung ke proyek untuk hampir semuanya. Sekelompok Kerangka Jython + Robot sudah bekerja di sana, basis kode besar (ditulis pada Kerangka Robot DSL itu sendiri) dikumpulkan dari lebih dari 1000 tes dan beberapa ribu baris kode perpustakaan bantu di Jawa.
Seperti yang saya pahami, ketika proyek dimulai, yaitu bahkan sebelum saya datang ke departemen, sebagian besar spesialis Jawa yang mengerjakannya, dan produk yang diuji sendiri di Jawa, jadi ketika memilih pendekatan, kami fokus pada sumber daya yang tersedia. Secara umum, perhitungannya kira-kira seperti ini: setelah menyelesaikan beberapa masalah terkait dengan integrasi Kerangka Robot dan Java (terutama karena fakta bahwa Java adalah bahasa yang dikompilasi, tetapi Python dan tes yang sama dalam bundel Python + RF ditafsirkan), kemudian mudah untuk menarik pakar pihak ketiga yang hanya tahu Kerangka Robot DSL, dan menulis tes kata kunci secara diam-diam. Benar, kolega harus menghabiskan banyak usaha dalam menciptakan perpustakaan di Jawa, oleh karena itu, tanpa persyaratan dari pelanggan, mereka tidak akan merekomendasikan jalan seperti itu.
Setelah melakukan sedikit refactoring, sebagai bagian dari tugas pertama saya, saya pertama kali menjalankan tes. Karena bundel Jython + RF digunakan, semuanya dikumpulkan oleh maven, dan file robot disalin ke direktori target untuk dieksekusi nanti.
Pengujian dijalankan oleh skrip (file .bat atau .sh) yang mengambil jalur ke kasus uji terpisah (file .robot terpisah) atau rencana pengujian (file dengan daftar jalur relatif untuk menguji kasus).
Refactoring memengaruhi sejumlah besar tes, sehingga uji coba pertama memakan waktu sekitar 15 menit. Setelah selesai, saatnya untuk melihat laporan yang disediakan oleh Robot Framework.
Laporan standar (dalam tangkapan layar di atas) terdiri dari file report.html dan log.html:
- laporan berisi ringkasan umum dari menjalankan terakhir, di mana Anda dapat melihat hasil permukaan dari semua tes (Lulus atau Gagal);
- dalam file log Anda dapat melihat informasi lebih rinci - pelaksanaan setiap langkah uji demi langkah. Di sana Anda dapat menampilkan semua yang Anda butuhkan untuk melakukan debug tes.
Jujur, dari pandangan pertama pada laporan Kerangka Robot, mata mulai bergerak sedikit: sejumlah besar informasi ditampilkan dan butuh beberapa waktu untuk memahami struktur ujung-ke-ujung dari tes dan mengembangkan keterampilan untuk membaca log seperti itu. Tetapi bisnis ini tidak begitu rumit. Dalam beberapa bulan saya dapat mengutip The Matrix: “Otak Anda yang menerjemahkannya. Saya bahkan tidak melihat kodenya. Saya melihat seorang pirang, berambut cokelat dan berambut merah. " Jadi saya - melihat semua informasi yang diperlukan dalam file tanpa alat tambahan.
Nilai tambahnya adalah output dapat dikontrol: ada beberapa level logging yang menentukan informasi mana yang akan ditampilkan dan mana yang tidak. Tingkat dapat disesuaikan bahkan untuk setiap baris secara individual melalui metode perpustakaan built-in. Pada saat yang sama, mengetahui urutan melakukan panggilan di dalam perpustakaan tes dan tambahan tidak berlebihan - lebih mudah untuk menangkap momen kesalahan.
Menggunakan Kerangka Robot DSL sebagai alat utama kami, kami bekerja selama sekitar enam bulan. Selama waktu ini, saya beralih dari preferensi pribadi dari Atom ke VSCode, tetapi ini tidak mengubah esensi dari pendekatan tersebut.
Namun, proyek itu berkembang. Dalam iterasi akhir, perpustakaan bantu untuk bekerja dengan database berjumlah 6.700 baris kode pada Kerangka Robot murni. Dengan skala basis kode seperti itu, menjadi sulit untuk mempertahankan - refactoring sumber daya yang diperlukan yang tidak dialokasikan.
Kata terakhir dalam menerapkan pendekatan pertama adalah milik bisnis. Pelanggan proyek kami juga bekerja dengan tim lain dalam tugas terkait. Di salah satu jalur paralel, ia melihat, dari sudut pandangnya, opsi yang lebih efektif dan ilustratif untuk menggunakan Robot Framework, yang mulai diterapkan khusus untuk manajemen.
Pendekatan kedua
Pendekatan kedua adalah pengembangan tes di Python dalam hubungannya dengan Kerangka Robot. Alih-alih membuat segala sesuatu di sintaks DSL Robot Framework, kami mulai menulis pustaka pembantu dan interaksi tingkat rendah lainnya dengan produk uji di Python. Dan Kerangka Robot, pada kenyataannya, menjadi hanya pelari.
Karena Python adalah bahasa tingkat tinggi murni, bukan DSL, ada lebih banyak opsi penataan, lebih mudah untuk mencari tahu semuanya. Minimal, Anda dapat menggunakan IDE Python untuk membantu Anda menemukan metode yang sama (mereka melakukan hal yang sama, tetapi disebut berbeda) atau bahkan menulis sepotong kode untuk Anda. Beberapa data dapat dibungkus dengan generator, menggantung dekorator pada fungsi, dll. Terhadap latar belakang ini, alat pendekatan pertama (Kerangka Robot murni) terlihat agak keras - pada kenyataannya, itu adalah Notepad dengan highlight sintaks. Tidak ada setter atau getter yang ditulis IntelliJ untuk Anda. Jadi saya senang kembali ke bahasa tingkat yang lebih tinggi. Bekerja dengan pendekatan ini lebih seperti perkembangan normal. Benar, ada lalat di salep. Tanpa tambahan tarian, tidak mungkin untuk memahami apa yang jatuh di dalam Python, yang disebut dari RF.
Perlahan, tes pertama dan perpustakaan tambahan untuk subsistem kami mulai ditulis. Selama saya bisa bekerja dengan pendekatan baru, saya merasa bahwa dengan alat lain benar-benar ada lebih banyak peluang. Namun pada kenyataannya, penulisan tes tidak banyak berubah. Dalam proyek khusus ini, di dalam kode Python, metode pustaka Robot Framework built-in masih dipanggil. Hal ini disebabkan oleh persyaratan khusus pelanggan untuk pengembangan tes. Kami hanya memisahkan bagian yang dapat dieksekusi dari algoritma kasus uji.
Mana yang lebih baik?
Saya pribadi menyukai pendekatan kedua. Namun, memilih jalur proyek Anda, ada baiknya dimulai dari tugas - siapa yang menulis tes dan bagaimana.
Seperti yang saya katakan di atas, Python (pendekatan kedua) memberikan lebih banyak peluang, tetapi dalam hal ini, orang-orang yang terbiasa dengan bahasa ini diperlukan pada proyek. Kerangka Robot itu sendiri (dan pendekatan pertama) kurang menuntut - Anda dapat mendekatinya dengan membaca dokumentasi resmi pada DSL-nya. Setelah mempelajari panduan pengguna, Anda dapat membuat tes apa pun - tes tersebut akan terlihat cukup bersih.
Akibatnya, Kerangka Robot dan cara kami menggunakannya pada awalnya lebih cocok untuk penguji manual kemarin tanpa pengalaman pemrograman yang eksplisit dalam bahasa tingkat tinggi. Bahkan orang yang tidak terlalu terlibat dalam pemrograman dapat menulis tes, hanya dengan memanggil kata kunci yang diperlukan.
Namun, jika Anda ingin menjaga bagian yang dapat dieksekusi terpisah, mengikuti contoh proyek kami, dan pada saat yang sama refactor kode dalam IDE ramah, pendekatan kedua adalah untuk Anda.
Penulis artikel: Dmitry Masters
PS: Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami di
VK ,
FB atau
saluran Telegram untuk mencari tahu tentang semua publikasi kami dan berita Maxilect lainnya.