Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development

Menguji Kode Ruby Anda Dengan Guard, RSpec & Pry: Bagian 2

by
Read Time:19 minsLanguages:

Indonesian (Bahasa Indonesia) translation by Sulistiyono (you can also view the original English article)

Selamat datang kembali! Jika Anda melewatkan bagian pertama dari perjalanan kami sejauh ini, maka Anda mungkin ingin kembali dan mengejar ketinggalan terlebih dahulu.

Sejauh ini, kami telah menerapkan proses Pengembangan Berbasis Tes untuk membangun aplikasi kami, di samping memanfaatkan kerangka pengujian RSpec yang populer. Dari sini, kita akan menyelidiki beberapa fitur RSpec lainnya serta melihat ke dalam menggunakan permata Pry untuk membantu Anda men-debug dan menulis kode Anda.

Fitur RSpec lainnya

Mari luangkan waktu sejenak untuk meninjau beberapa fitur RSpec lain yang tidak kita perlukan dalam aplikasi contoh sederhana ini, tetapi Anda mungkin menemukan pekerjaan yang berguna pada proyek Anda sendiri.

Pernyataan Tertunda

Bayangkan Anda menulis tes tetapi Anda terganggu, atau Anda harus pergi untuk rapat dan belum menyelesaikan kode yang diperlukan untuk mendapatkan tes untuk lulus.

Anda dapat menghapus tes dan menulis kembali nanti ketika Anda dapat kembali ke pekerjaan Anda. Atau sebagai alternatif Anda bisa saja berkomentar kode keluar, tapi itu cukup jelek dan jelas tidak baik ketika menggunakan sistem kontrol versi.

Hal terbaik untuk dilakukan dalam situasi ini adalah mendefinisikan tes kami sebagai 'menunggu' sehingga setiap kali tes dijalankan, kerangka uji akan mengabaikan tes. Untuk melakukan ini, Anda perlu menggunakan kata kunci yang tertunda:

Set-Up dan Tear-Down

Semua kerangka kerja pengujian yang baik memungkinkan Anda untuk mengeksekusi kode sebelum dan setelah setiap pengujian dijalankan. RSpec tidak berbeda.

Ini memberikan kita metode sebelum dan sesudah yang memungkinkan kita untuk mengatur kondisi tertentu agar pengujian kita dapat berjalan, dan untuk kemudian membersihkan keadaan itu setelah pengujian berjalan (ini adalah agar negara tidak bocor dan mempengaruhi hasil dari tes selanjutnya).

Blok Konteks

Kami telah melihat blok uraian; tetapi ada blok lain yang secara fungsional setara disebut konteks. Anda dapat menggunakannya di mana saja Anda akan menggunakan deskripsi.

Perbedaan di antara mereka tidak kentara tetapi penting: konteks memungkinkan kita untuk menentukan keadaan untuk pengujian kita. Namun tidak secara eksplisit (kami tidak benar-benar mengatur keadaan dengan mendefinisikan blok konteks - melainkan untuk tujuan keterbacaan sehingga maksud dari kode berikut ini lebih jelas).

Berikut ini sebuah contoh:

Stubs

Kita dapat menggunakan metode rintisan untuk membuat versi palsu dari objek yang ada dan mengembalikannya ke nilai yang ditentukan sebelumnya.

Ini berguna untuk mencegah pengujian kami dari menyentuh API layanan langsung, dan memandu pengujian kami dengan memberikan hasil yang dapat diprediksi dari panggilan tertentu.

Bayangkan kita memiliki kelas bernama Person dan kelas ini memiliki metode berbicara. Kami ingin menguji bahwa metode itu berfungsi seperti yang kami harapkan. Untuk melakukan ini kita akan mematikan metode berbicara menggunakan kode berikut:

Dalam contoh ini, kita mengatakan bahwa 'instance' dari kelas Person harus memiliki metode inisialisasi yang dihapus sehingga mengembalikan objek bob.

Anda akan melihat bahwa bob itu sendiri adalah sebuah rintisan yang diatur sehingga setiap kode waktu mencoba mengeksekusi metode bicara itu akan mengembalikan "halo".

Kami kemudian melanjutkan untuk membuat instance Orang baru dan meneruskan panggilan instance.speak ke sintaks harapan RSpec.

Kami memberi tahu RSpec bahwa kami mengharapkan panggilan itu menghasilkan String "halo".

Nilai Pengembalian Berurutan

Dalam contoh sebelumnya kita telah menggunakan fitur and_return RSpec untuk menunjukkan apa yang harus dikembalikan oleh rintisan kita ketika dipanggil.

Kami dapat menunjukkan nilai pengembalian yang berbeda setiap kali rintisan dipanggil dengan menetapkan beberapa argumen ke metode and_return:

Mengejek

Mock mirip dengan Rintisan bertopik di mana kita membuat versi palsu dari objek kita, tetapi bukannya mengembalikan nilai yang telah ditentukan kita lebih khusus memandu rute yang harus diambil objek kita agar tes itu valid.

Untuk melakukan itu kita menggunakan metode mock:

Dalam contoh di atas kita membuat instance Object baru dan kemudian memanggil metode pengujiannya.

Di balik layar kode itu kami mengharapkan metode pengujian dipanggil dengan nilai 'konten'. Jika tidak dipanggil dengan nilai itu (yang dalam contoh di atas tidak) maka kita tahu bahwa sebagian kode kita belum berfungsi dengan baik.

Subject Block

Kata kunci subjek dapat digunakan dalam beberapa cara berbeda. Semuanya dirancang untuk mengurangi duplikasi kode.

Anda dapat menggunakannya secara implisit (perhatikan bahwa blok kami tidak merujuk subjek sama sekali):

Anda dapat menggunakannya secara eksplisit (perhatikan bahwa blok kami merujuk ke subjek secara langsung):

Daripada terus-menerus mereferensikan subjek dalam kode Anda dan memberikan nilai yang berbeda untuk instantiasi, misalnya:

Anda bisa menggunakan subjek bersamaan dengan membiarkan untuk mengurangi duplikasi:

Ada banyak lagi fitur yang tersedia untuk RSpec, tetapi kami telah melihat yang paling penting yang akan banyak Anda gunakan saat menulis tes menggunakan RSpec.

Tes Acak

Anda dapat mengkonfigurasi RSpec untuk menjalankan tes Anda secara acak. Ini memungkinkan Anda untuk memastikan bahwa tidak ada tes yang memiliki ketergantungan atau ketergantungan pada tes lain di sekitarnya.

Anda dapat mengatur ini melalui perintah menggunakan --order flag / option. Sebagai contoh: rspec --order acak.

Saat Anda menggunakan opsi --order random, RSpec akan menampilkan nomor acak yang digunakan untuk seed algoritma. Anda dapat menggunakan nilai 'seed' ini lagi ketika Anda berpikir Anda telah menemukan masalah ketergantungan dalam tes Anda. Setelah Anda memperbaiki apa yang Anda pikir masalah, Anda dapat meneruskan nilai seed ke RSpec (mis. Jika seed tersebut 1234 lalu jalankan --order random: 1234) dan ia akan menggunakan seed acak yang sama untuk melihat apakah ia dapat mereplikasi bug ketergantungan asli.

Konfigurasi Global

Anda telah melihat kami telah menambahkan satu set objek konfigurasi khusus proyek dalam Rakefile kami. Tetapi Anda dapat mengatur opsi konfigurasi secara global dengan menambahkannya ke file .rspec dalam direktori home Anda.

Misalnya, di dalam .rspec:

Debugging Dengan Pry

Sekarang kita siap untuk mulai mencari tahu bagaimana kita bisa men-debug aplikasi kita dan kode uji kita menggunakan permata Pry.

Penting untuk dipahami bahwa meskipun Pry benar-benar bagus untuk men-debug kode Anda, sebenarnya Pry dimaksudkan sebagai alat Ruby REPL yang ditingkatkan (untuk menggantikan irb) dan bukan tujuan debugging secara ketat; jadi misalnya tidak ada fungsi bawaan seperti: melangkah masuk, melangkah keluar atau melangkah keluar dll yang biasanya Anda temukan di alat yang dirancang untuk debugging.

Tetapi sebagai alat debugging, Pry sangat fokus dan ramping.

Kami akan kembali ke debugging sebentar, tetapi mari kita tinjau dulu bagaimana kita akan menggunakan Pry pada awalnya.

Contoh Kode yang Diperbarui

Untuk tujuan mendemonstrasikan Pry, saya akan menambahkan lebih banyak kode ke aplikasi contoh saya (kode tambahan ini tidak mempengaruhi pengujian kami dengan cara apa pun)

Anda akan melihat kami telah menambahkan beberapa metode tambahan, instance, dan properti kelas. Kami juga melakukan panggilan ke dua metode baru yang kami tambahkan dari dalam metode sapaan kami.

Terakhir, Anda akan melihat penggunaan binding.pry.

Mengatur Break-Points Dengan binding.pry

Break-point adalah tempat di dalam kode Anda di mana eksekusi akan berhenti.

Anda dapat memiliki beberapa break-point yang ditetapkan dalam kode Anda dan Anda membuatnya menggunakan binding.pry.

Ketika Anda menjalankan kode Anda, Anda akan melihat bahwa terminal akan berhenti dan menempatkan Anda di dalam kode aplikasi Anda di tempat yang tepat binding.pry Anda ditempatkan.

Di bawah ini adalah contoh bagaimana tampilannya ...

Dari titik ini Pry memiliki akses ke lingkup lokal sehingga Anda dapat menggunakan Pry seperti yang Anda lakukan di irb dan mulai mengetikkan variabel contoh untuk melihat nilai apa yang mereka pegang.

Anda dapat menjalankan perintah keluar untuk keluar dari Pry dan agar kode Anda terus dijalankan.

Finding Where You Are: whereami

Saat menggunakan banyak titik jilid binding.pry, mungkin sulit untuk memahami di mana dalam aplikasi Anda.

Untuk mendapatkan konteks yang lebih baik di mana Anda berada pada titik mana pun, Anda bisa menggunakan perintah whereami.

Saat dijalankan sendiri, Anda akan melihat sesuatu yang mirip dengan saat Anda menggunakan binding.pry (Anda akan melihat garis di mana break-point ditetapkan dan beberapa baris di atas dan di bawahnya). Perbedaannya adalah jika Anda memberikan argumen numerik tambahan seperti whereami 5 Anda akan melihat lima baris tambahan di atas tempat binding.pry ditempatkan. Anda dapat meminta untuk melihat 100 baris di sekitar break-point saat ini misalnya.

Perintah ini dapat membantu mengarahkan Anda ke dalam file saat ini.

Stack Trace: wtf

Perintah wtf adalah singkatan dari "what the f ***" dan ini memberikan jejak stack penuh untuk pengecualian terbaru yang telah dilemparkan. Ini dapat membantu Anda memahami langkah-langkah menuju kesalahan yang terjadi.

Memeriksa: ls

Perintah ls menampilkan metode dan properti apa yang tersedia untuk Pry.

Saat dijalankan akan menampilkan sesuatu seperti ...

Dalam contoh di atas kita dapat melihat bahwa kita memiliki empat metode publik (ingat kita memperbarui kode kita untuk memasukkan beberapa metode tambahan dan kemudian tes dan uji = dibuat ketika menggunakan tangan pendek Ruby attr_accessor).

Itu juga menampilkan kelas lain dan variabel lokal Pry dapat mengakses.

Hal lain yang berguna yang dapat Anda lakukan adalah untuk menangkap (mencari) hasil hanya untuk apa yang Anda minati. Anda harus memiliki pemahaman tentang Ekspresi Reguler tetapi itu bisa menjadi teknik yang berguna. Berikut ini sebuah contoh ...

Dalam contoh di atas kita menggunakan opsi -p dan -G opsi / flag yang memberitahu Pry kita hanya ingin melihat metode publik dan pribadi dan kita menggunakan regex ^ p (yang artinya cocok dengan apa pun yang dimulai dengan p) sebagai pola pencarian kita untuk saring hasilnya.

Menjalankan ls --help juga akan menampilkan semua opsi yang tersedia.

Mengubah Ruang Lingkup: cd

Anda dapat mengubah ruang lingkup saat ini dengan menggunakan perintah cd.

Dalam contoh kita jika kita menjalankan cd ../pub akan membawa kita ke hasil pemanggilan metode itu.

Jika sekarang kita jalankan whereami Anda akan melihatnya akan menampilkan Inside "I'm a test variable".

Jika kita menjalankan self maka kita akan melihat kita mendapatkan "I'm a test variable" dikembalikan.

Jika kita menjalankan self.class kita akan melihat String kembali.

Anda dapat naik ke rantai lingkup menggunakan cd .. atau Anda dapat kembali ke tingkat atas lingkup menggunakan cd /.

Catatan: kita bisa menambahkan binding.pry lain di dalam metode pub dan kemudian ruang lingkup kita akan berada di dalam metode itu daripada hasil dari metode tersebut.

Serapa Dalam Diri Anda: nesting

Perhatikan contoh menjalankan cd pubs sebelumnya. Jika kita menjalankan perintah nesting kita akan mendapatkan tampilan tingkat atas pada jumlah konteks / level yang saat ini dimiliki Pry:

Dari sana kita dapat menjalankan exit untuk kembali ke konteks sebelumnya (misalnya, di dalam metode sapaan)

Menjalankan exit lagi akan berarti kita menutup konteks terakhir yang Pry miliki dan Pry selesai dan kode kita terus berjalan.

Temukan Semua Metode: find-method

Jika Anda tidak yakin di mana menemukan metode tertentu, maka Anda dapat menggunakan perintah find-method untuk menampilkan semua file dalam basis kode Anda yang memiliki metode yang cocok dengan apa yang Anda cari:

Anda juga dapat menggunakan opsi -c / flag untuk mencari konten file sebagai gantinya:

Debugging Klasik: nextstepcontinue

Meskipun teknik-teknik di atas berguna, itu tidak benar-benar 'debugging' dalam arti yang sama seperti apa yang Anda mungkin terbiasa.

Bagi sebagian besar pengembang, editor atau peramban mereka akan menyediakan alat debugging bawaan yang memungkinkan mereka benar-benar melangkah melalui kode baris demi baris dan mengikuti rute yang dibutuhkan kode hingga selesai.

Karena Pry dikembangkan untuk digunakan sebagai REPL, itu tidak berarti itu tidak berguna untuk debugging.

Solusi naif adalah dengan mengatur beberapa pernyataan binding.pry melalui metode dan menggunakan ctrl-d untuk bergerak melalui setiap set break-point. Tapi itu masih belum cukup baik.

Untuk debugging langkah demi langkah Anda dapat memuat pry-nav ...

Permata ini memperpanjang Pry sehingga memahami perintah berikut:

  • Next (pindah ke baris berikutnya)
  • Step (pindah ke baris berikutnya dan jika ini adalah metode, maka pindahlah ke metode itu)
  • Continue (Abaikan setiap break-point lebih lanjut dalam file ini)

Integrasi Berkelanjutan Dengan Travis-CI

Sebagai bonus tambahan mari kita mengintegrasikan pengujian kami dengan layanan CI online (integrasi berkelanjutan) Travis-CI.

Prinsip CI adalah untuk melakukan / mendorong lebih awal dan sering untuk menghindari konflik antara kode Anda dan cabang utama. Ketika Anda melakukannya (dalam hal ini kami berkomitmen untuk GitHub) maka itu akan memulai 'build' pada server CI Anda yang menjalankan tes yang relevan untuk memastikan semua berfungsi sebagaimana mestinya.

Sekarang dengan TDD sebagai metodologi pengembangan utama Anda, Anda cenderung tidak menimbulkan bug setiap kali Anda mendorong karena tes Anda merupakan bagian integral dari alur kerja pengembangan Anda dan sebelum Anda mendorong Anda akan sudah menyadari bug atau regresi. Tetapi ini tidak selalu melindungi Anda dari bug yang terjadi dari tes integrasi (di mana semua kode di beberapa sistem dijalankan bersama untuk memastikan sistem 'secara keseluruhan' berfungsi dengan benar).

Apapun, kode tidak boleh didorong langsung ke server produksi langsung Anda dengan cara apa pun; itu harus selalu didorong terlebih dahulu ke server CI untuk membantu menangkap bug potensial yang timbul dari perbedaan antara lingkungan pengembangan Anda dan lingkungan produksi.

Banyak perusahaan masih memiliki lebih banyak lingkungan untuk dilewati kode mereka sebelum mencapai server produksi langsung.

Misalnya, di BBC News, kami memiliki:

  • CI
  • Test
  • Stage
  • Live

Meskipun masing-masing lingkungan harus identik dalam pengaturan, tujuannya adalah untuk menerapkan berbagai jenis pengujian untuk memastikan sebanyak bug terdeteksi dan diselesaikan sebelum kode mencapai 'hidup'.

Travis-CI

Travis CI adalah layanan integrasi berkesinambungan yang dihosting untuk komunitas sumber terbuka. Ini terintegrasi dengan GitHub dan menawarkan dukungan kelas satu untuk berbagai bahasa

Artinya, Travis-CI menawarkan layanan CI gratis untuk proyek-proyek sumber terbuka dan juga memiliki model berbayar untuk bisnis dan organisasi yang ingin menjaga integrasi CI mereka tetap pribadi.

Kami akan menggunakan model open-source gratis pada contoh repositori GitHub kami.

Prosesnya adalah ini:

  • Daftarkan akun dengan GitHub
  • Masuk ke Travis-CI menggunakan akun GitHub Anda
  • Buka halaman "Akun" Anda
  • Nyalakan "repositori apa pun yang Anda inginkan untuk menjalankan CI
  • Buat file .travis.yml di dalam direktori root proyek Anda dan komit ke repositori GitHub Anda

Langkah terakhir adalah yang paling penting (membuat file .travis.yml) karena ini menentukan pengaturan konfigurasi untuk Travis-CI sehingga ia tahu cara menangani menjalankan tes untuk proyek Anda.

Mari kita lihat file .travis.yml yang kita gunakan untuk repositori GitHub contoh kita:

Mari kita hancurkan ini sepotong demi sepotong ...

Pertama kami menentukan bahasa apa yang kami gunakan dalam proyek kami. Dalam hal ini kami menggunakan Ruby: bahasa: ruby.

Karena menjalankan Bundler bisa agak lambat dan kami tahu bahwa dependensi kami tidak akan berubah yang sering kali kami dapat memilih untuk cache dependensi, jadi kami menetapkan cache: bundler.

Travis-CI menggunakan RVM (Ruby Version Manager) untuk menginstal Rubi di server mereka. Jadi kita perlu menentukan versi Ruby yang ingin kita jalankan pengujiannya. Dalam contoh ini kami telah memilih 2.0 dan 1.9.3 yang merupakan dua versi Ruby yang populer (secara teknis aplikasi kami menggunakan Ruby 2 tetapi ada baiknya mengetahui kode kami melewati versi Ruby yang lain juga):

Untuk menjalankan tes kami, kami tahu bahwa kami dapat menggunakan perintah rake atau rake spec. Travis-CI secara default menjalankan perintah rake tetapi karena bagaimana Permata diinstal pada Travis-CI menggunakan Bundler kita perlu mengubah perintah default: script: 'bundle exec rake spec'. Jika kita tidak melakukan ini maka Travis-CI akan memiliki masalah menemukan file rspec / core / rake_task yang ditentukan dalam Rakefile kami.

Catatan: jika Anda memiliki masalah apa pun tentang Travis-CI maka Anda dapat bergabung dengan saluran #travis di IRC freenode untuk mendapatkan bantuan menjawab pertanyaan yang mungkin Anda miliki. Di situlah saya menemukan solusi untuk masalah saya dengan Travis-CI tidak dapat menjalankan tes saya menggunakan perintah rake default dan saran untuk menimpa default dengan bundle exec rake menyelesaikan masalah itu.

Selanjutnya, karena kami hanya tertarik untuk menjalankan pengujian kami, kami dapat memberikan argumen tambahan ke Travis-CI untuk memfilter permata yang tidak ingin kami pasang. Jadi bagi kami, kami ingin mengecualikan pemasangan permata yang dikelompokkan sebagai pengembangan: bundler_args: --tanpa pengembangan (ini berarti kami mengecualikan permata yang hanya benar-benar digunakan untuk pengembangan dan debugging seperti Pry dan Guard).

Penting untuk dicatat bahwa awalnya saya memuat Pry dalam file spec_helper.rb kami. Ini menyebabkan masalah ketika menjalankan kode pada Travis-CI, sekarang saya tidak menyertakan permata 'pengembangan'. Jadi saya harus mengubah kode seperti ini:

Anda dapat melihat bahwa sekarang permata Pry hanya diperlukan jika variabel lingkungan APP_ENV diatur ke debug. Dengan cara ini kita dapat menghindari Travis-CI dari melakukan kesalahan. Ini berarti bahwa ketika menjalankan kode Anda secara lokal, Anda perlu mengatur variabel lingkungan jika Anda ingin men-debug kode Anda menggunakan Pry. Berikut ini menunjukkan bagaimana ini dapat dilakukan dalam satu baris:

Ada dua perubahan lain yang saya buat dan itu untuk Gemfile kami. Satu untuk memperjelas permata apa yang diperlukan untuk pengujian dan mana yang diperlukan untuk pengembangan, dan yang lainnya secara eksplisit diminta oleh Travis-CI:

Melihat Gemfile yang diperbarui di atas, kita dapat melihat kita telah memindahkan permata RSpec ke grup uji baru, jadi sekarang seharusnya lebih jelas apa tujuan setiap permata. Kami juga telah menambahkan baru gem 'rake'. Dokumentasi Travis-CI menyatakan ini perlu ditentukan secara eksplisit.

Bagian selanjutnya adalah opsional dan memungkinkan Anda untuk membuat daftar putih (atau daftar hitam) cabang-cabang tertentu di repositori Anda. Jadi secara default Travis-CI akan menjalankan tes terhadap semua cabang Anda kecuali Anda memberi tahu sebaliknya. Dalam contoh ini kita mengatakan kita hanya ingin menjalankan terhadap cabang master kami:

Kami dapat memerintahkannya untuk menjalankan setiap cabang 'kecuali' cabang tertentu, seperti:

Bagian terakhir memberitahu Travis-CI ke mana harus mengirim pemberitahuan ketika sebuah bangunan gagal atau berhasil:

Anda dapat menentukan beberapa alamat email jika Anda ingin:

Anda dapat lebih spesifik dan menentukan apa yang Anda inginkan terjadi pada kegagalan atau keberhasilan (misalnya, lebih banyak orang hanya akan tertarik jika tes gagal daripada mendapatkan email setiap kali mereka lulus):

Contoh di atas menunjukkan bahwa penerima tidak akan pernah menerima email jika tes lulus tetapi akan diberi tahu jika status kegagalan berubah (nilai default untuk keduanya selalu yang berarti Anda akan selalu diberi tahu terlepas dari apa hasil statusnya).

Catatan: ketika Anda secara eksplisit menentukan on_failure atau on_success Anda perlu memindahkan alamat email di dalam kunci penerima.

Kesimpulan

Ini adalah akhir dari dua bagian kami melihat ke RSpec, TDD dan Pry.

Pada bagian satu kami berhasil menulis aplikasi kami menggunakan proses TDD dan kerangka pengujian RSpec. Di babak kedua ini kami juga telah memanfaatkan Pry untuk menunjukkan bagaimana kami dapat lebih mudah men-debug aplikasi Ruby yang sedang berjalan. Akhirnya, kami dapat menjalankan set pengujian kami sebagai bagian dari server integrasi berkelanjutan menggunakan layanan Travis-CI yang populer.

Semoga ini memberi Anda cukup rasa sehingga Anda tertarik untuk menyelidiki masing-masing teknik ini lebih lanjut.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.