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

by
Read Time:15 minsLanguages:

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

Pekerjaan terbaru saya adalah proyek Ruby berbasis cloud untuk BBC News, pemilu 2014 mendatang. Ini membutuhkan I / O yang cepat, skalabilitas dan perlu diuji dengan baik. Persyaratan "teruji dengan baik", adalah apa yang ingin saya fokuskan dalam tutorial ini.

pengantar

Proyek ini menggunakan beberapa layanan Amazon yang berbeda seperti:

  • SQS (Layanan Antrian Sederhana)
  • DynamoDB (penyimpanan kunci / nilai)
  • S3 (Layanan Penyimpanan Sederhana)

Kami harus dapat menulis tes yang cepat dan memberi kami umpan balik instan tentang masalah dengan kode kami.

Meskipun, kita tidak akan menggunakan layanan Amazon dalam tutorial ini, saya menyebutkannya karena bagi kita untuk memiliki tes yang cepat, itu mengharuskan kita untuk memalsukan objek eksternal ini (misalnya, kita seharusnya tidak memerlukan koneksi jaringan untuk menjalankan tes, karena ketergantungan itu dapat mengakibatkan tes berjalan lambat).

Bersama pimpinan teknologi Robert Kenny (yang sangat berpengalaman dalam menulis aplikasi Ruby berbasis TDD (test-driven development)) kami telah menggunakan berbagai alat yang membuat proses ini dan pemrograman kami bekerja jauh lebih mudah.

Saya ingin berbagi beberapa informasi tentang alat-alat ini dengan Anda.

Alat yang akan saya bahas adalah:

Apa yang Harus Saya Ketahui di Awal?

Saya akan membuat asumsi bahwa Anda terbiasa dengan kode Ruby dan sistem lingkungan Ruby. Sebagai contoh, saya tidak perlu menjelaskan kepada Anda apa 'permata' atau bagaimana sintaks / konsep Ruby tertentu bekerja.

Jika Anda tidak yakin, maka sebelum Anda pindah, aktif saya sarankan membaca salah satu posting saya yang lain di Ruby untuk meningkatkan kecepatan Anda.

Guard

Anda mungkin tidak terbiasa dengan Guard, tetapi pada dasarnya itu adalah alat baris perintah yang memanfaatkan Ruby untuk menangani berbagai peristiwa.

Misalnya, Guard dapat memberi tahu Anda kapan pun file tertentu telah diedit dan Anda dapat melakukan beberapa tindakan berdasarkan jenis file atau peristiwa yang dipecat.

Ini dikenal sebagai 'pelari tugas', Anda mungkin pernah mendengar ungkapan sebelumnya, karena mereka banyak menggunakan dunia front-end / sisi klien saat ini (Grunt dan Gulp adalah dua contoh populer).

Alasan kami menggunakan Guard adalah karena ini membantu membuat loop umpan balik (ketika melakukan TDD) jauh lebih ketat. Itu memungkinkan kita untuk mengedit file pengujian kita, melihat pengujian yang gagal, memperbarui dan menyimpan kode kita dan segera melihat apakah itu lulus atau gagal (tergantung pada apa yang kita tulis).

Anda bisa menggunakan sesuatu seperti Grunt atau Gulp, tetapi kami lebih suka menggunakan jenis-jenis pelari tugas untuk menangani hal-hal front-end / sisi klien. Untuk kode back-end / server-side, kami menggunakan Rake dan Guard.

RSpec

RSpec, jika Anda belum sadar, adalah alat pengujian untuk bahasa pemrograman Ruby.

Anda menjalankan tes Anda (menggunakan RSpec) melalui baris perintah dan saya akan menunjukkan bagaimana Anda dapat membuat proses ini lebih mudah melalui penggunaan program build Ruby, Rake.

Pry

Terakhir, kami akan menggunakan permata Ruby lain yang disebut Pry yang merupakan alat debugging Ruby yang sangat kuat yang menyuntikkan dirinya ke dalam aplikasi Anda, saat sedang berjalan, untuk memungkinkan Anda memeriksa kode Anda dan mencari tahu mengapa sesuatu tidak berfungsi.

TDD (Pengembangan Berbasis Tes)

Meskipun tidak perlu untuk menunjukkan penggunaan RSpec dan Guard, perlu dicatat bahwa saya sepenuhnya mendukung penggunaan TDD sebagai cara untuk memastikan setiap baris kode yang Anda tulis memiliki tujuan dan telah dirancang dengan cara yang dapat diuji dan dapat diandalkan.

Saya akan merinci bagaimana kita akan melakukan TDD dengan aplikasi sederhana, jadi setidaknya Anda akan merasakan bagaimana prosesnya bekerja.

Membuat Proyek Contoh

Saya telah membuat contoh dasar tentang GitHub untuk menyelamatkan Anda dari keharusan mengetik semuanya sendiri. Silakan mengunduh kodenya.

Sekarang mari kita lanjutkan dan tinjau proyek ini, langkah demi langkah.

Primary Files

Ada tiga file utama yang diperlukan agar aplikasi contoh kita berfungsi, yaitu:

  1. Gemfile
  2. Guardfile
  3. Rakefile

Kami akan membahas isi setiap file segera, tetapi hal pertama yang perlu kami lakukan adalah mendapatkan struktur direktori kami di tempat.

Struktur Direktori

Untuk proyek contoh kami, kami membutuhkan dua folder yang dibuat:

  • lib (ini akan menyimpan kode aplikasi kami)
  • spec (ini akan menyimpan kode pengujian kami)

Ini bukan persyaratan untuk aplikasi Anda, Anda dapat dengan mudah mengubah kode dalam file kami yang lain untuk bekerja dengan struktur apa pun yang cocok untuk Anda.

Instalasi

Buka terminal Anda dan jalankan perintah berikut:

Bundler adalah alat yang mempermudah pemasangan permata lain.

Setelah Anda menjalankan perintah itu, buat tiga file di atas (Gemfile, Guardfile dan Rakefile).

Gemfile

Gemfile bertanggung jawab untuk menentukan daftar dependensi untuk aplikasi kita.

Berikut ini tampilannya:

Setelah file ini disimpan, jalankan bundle install.

Ini akan memasang semua permata kami untuk kami (termasuk permata yang ditentukan dalam grup development ).

Tujuan dari grup development (yang merupakan fitur spesifik bundler) adalah ketika Anda menggunakan aplikasi Anda, Anda dapat memberitahu lingkungan produksi Anda untuk menginstal hanya permata yang diperlukan agar aplikasi Anda berfungsi dengan baik.

Jadi misalnya, semua permata di dalam grup pengembangan, tidak diperlukan agar aplikasi berfungsi dengan baik. Mereka digunakan hanya untuk membantu kami saat kami sedang mengembangkan dan menguji kode kami.

Untuk memasang permata yang sesuai di server produksi Anda, Anda perlu menjalankan sesuatu seperti:

Rakefile

Rakefile akan memungkinkan kita untuk menjalankan tes RSpec dari baris perintah.

Berikut ini tampilannya:

Catatan: Anda tidak perlu Guard untuk dapat menjalankan tes RSpec Anda. Kami menggunakan Guard untuk mempermudah melakukan TDD.

Ketika Anda menginstal RSpec, itu memberi Anda akses ke tugas Rake bawaan dan itulah yang kami gunakan di sini.

Kami membuat instance baru RakeTask yang secara default membuat tugas yang disebut spec yang akan mencari folder yang disebut spec dan akan menjalankan semua file pengujian di dalam folder itu, menggunakan opsi konfigurasi yang telah kami tentukan.

Dalam contoh ini, kami ingin output shell kami memiliki warna dan kami ingin memformat output ke gaya doc (Anda dapat mengubah format yang akan disarangkan sebagai contoh).

Anda dapat mengonfigurasi tugas Rake untuk bekerja dengan cara apa pun yang Anda inginkan dan untuk melihat ke direktori yang berbeda, jika itu yang Anda miliki. Tetapi pengaturan default berfungsi baik untuk aplikasi kita dan itulah yang akan kita gunakan.

Sekarang jika saya ingin menjalankan tes dalam repositori GitHub contoh saya, maka saya perlu membuka terminal saya dan menjalankan perintah:

Ini memberi kami output berikut:

Seperti yang Anda lihat ada nol kegagalan. Itu karena meskipun kami tidak memiliki kode aplikasi yang ditulis, kami juga belum memiliki kode tes yang ditulis.

Guardfile

Isi file ini memberi tahu Guard apa yang harus dilakukan ketika kita menjalankan perintah guard:

Anda akan melihat di dalam Gemfile kami, kami menentukan permata: guard-rspec. Kami membutuhkan permata itu untuk memungkinkan Guard memahami cara menangani perubahan pada file terkait RSpec.

Jika kita melihat lagi kontennya, kita dapat melihat bahwa jika kita menjalankan guard rspec maka Guard akan menonton file yang ditentukan dan menjalankan perintah yang ditentukan setelah ada perubahan pada file tersebut.

Catatan: karena kita hanya memiliki satu tugas guard, rspec, maka itu dijalankan secara default jika kita menjalankan command guard.

Anda dapat melihat Guard memberi kami fungsi watch yang kami lewati Ekspresi Reguler untuk memungkinkan kami menentukan file apa yang kami minati menonton Guard.

Dalam contoh ini, kami memberi tahu Guard untuk menonton semua file dalam folder lib dan spec kami dan jika ada perubahan pada salah satu file itu maka untuk mengeksekusi file tes dalam folder spec kami untuk memastikan tidak ada perubahan yang kami lakukan batal pengujian kami (dan selanjutnya tidak merusak kode kami).

Jika Anda memiliki semua file yang diunduh dari repo GitHub maka Anda dapat mencoba sendiri perintahnya.

Jalankan guard dan kemudian simpan salah satu file untuk melihatnya menjalankan tes.

Kode Uji

Sebelum kita mulai melihat beberapa tes dan kode aplikasi, izinkan saya menjelaskan apa yang akan dilakukan aplikasi kita. Aplikasi kami adalah kelas tunggal yang akan mengembalikan pesan ucapan kepada siapa pun yang menjalankan kode.

Persyaratan kami sengaja disederhanakan, karena itu akan membuat proses yang akan kami lakukan lebih mudah dipahami.

Sekarang mari kita lihat contoh spesifikasi (misalnya, file pengujian kami) yang akan menjelaskan persyaratan kami. Setelah itu, kita akan mulai melangkah melalui kode yang ditentukan dalam spesifikasi dan melihat bagaimana kita dapat menggunakan TDD untuk membantu kita dalam menulis aplikasi kita.

Tes Pertama Kami

Kita akan membuat file berjudul example_spec.rb. Tujuan dari file ini adalah untuk menjadi file spesifikasi kami (dengan kata lain, ini akan menjadi kode pengujian kami dan akan mewakili fungsionalitas yang diharapkan).

Alasan kami menulis kode pengujian kami sebelum menulis kode aplikasi kami yang sebenarnya adalah karena pada akhirnya itu berarti bahwa setiap kode aplikasi yang kami hasilkan akan ada karena kode itu benar-benar digunakan.

Itu poin penting yang saya buat dan biarkan saya meluangkan waktu untuk menjelaskannya lebih terinci.

Menulis Kode Tes Sebelum Kode Aplikasi

Biasanya, jika Anda menulis kode aplikasi Anda terlebih dahulu (sehingga Anda tidak melakukan TDD), maka Anda akan menemukan diri Anda menulis kode yang pada suatu saat di masa depan sudah selesai direkayasa dan berpotensi usang. Melalui proses refactoring atau perubahan persyaratan, Anda mungkin menemukan bahwa beberapa fungsi akan gagal dipanggil.

Inilah sebabnya mengapa TDD dianggap sebagai praktik yang lebih baik dan metode pengembangan yang disukai untuk digunakan, karena setiap baris kode yang Anda hasilkan akan diproduksi karena suatu alasan: untuk mendapatkan spesifikasi yang gagal (persyaratan bisnis Anda yang sebenarnya) untuk dilewati. Itu hal yang sangat kuat untuk diingat.

Ini kode pengujian kami:

Anda dapat melihat komentar kode di akhir setiap baris:

  • Given
  • When
  • Then

Ini adalah bentuk terminologi BDD (Behavior-Driven Development). Saya menyertakan mereka untuk pembaca yang lebih akrab dengan BDD (Behavior-Driven Development) dan yang tertarik pada bagaimana mereka bisa menyamakan pernyataan ini dengan TDD.

Hal pertama yang kami lakukan di dalam file ini adalah memuat spec_helper.rb (yang ditemukan di direktori yang sama dengan file spec kami). Kami akan kembali dan melihat isi file itu sebentar lagi.

Selanjutnya kita memiliki dua blok kode yang khusus untuk RSpec:

  • describe 'x' do
  • it 'y' do

Blok describe pertama harus secara memadai menggambarkan kelas / modul spesifik yang sedang kami kerjakan dan menyediakan tes untuk. Anda bisa saja memiliki beberapa blok describe dalam satu file spesifikasi.

Ada banyak teori berbeda tentang bagaimana menggunakan menggambarkan dan mendeskripsikan blok. Saya pribadi lebih suka kesederhanaan dan jadi saya akan menggunakan pengidentifikasi untuk Kelas / Modul / Metode yang akan kami uji. Tetapi Anda sering menemukan beberapa orang yang lebih suka menggunakan kalimat lengkap untuk deskripsi mereka. Tidak ada yang benar atau salah, hanya preferensi pribadi.

Blok it berbeda dan harus selalu ditempatkan di dalam blok uraian. Itu harus menjelaskan bagaimana kita ingin aplikasi kita berfungsi.

Sekali lagi, Anda bisa menggunakan kalimat normal untuk menggambarkan persyaratan, tetapi saya menemukan bahwa kadang-kadang melakukan hal itu dapat menyebabkan deskripsi menjadi terlalu eksplisit, ketika mereka harus benar-benar lebih implisit. Menjadi kurang eksplisit mengurangi kemungkinan perubahan pada fungsionalitas Anda, menyebabkan deskripsi Anda menjadi usang (harus memperbarui deskripsi Anda setiap kali perubahan fungsionalitas kecil terjadi lebih merupakan beban daripada bantuan). Dengan menggunakan pengidentifikasi metode yang kami uji (misalnya, nama metode yang kami jalankan), kami dapat menghindari masalah itu.

Isi dari blok itu adalah kode yang akan kita uji.

Dalam contoh di atas, kami membuat instance baru dari kelas RSpecGreeter (yang belum ada). Kami mengirim salam pesan (yang juga belum ada) ke objek instantiated yang dibuat (catatan: dua baris ini adalah kode Ruby standar pada saat ini).

Akhirnya, kami memberi tahu kerangka pengujian bahwa kami mengharapkan hasil dari memanggil metode greet menjadi teks "Hello RSpec!", Dengan menggunakan sintaks RSpec: eq(something).

Perhatikan bagaimana sintaksnya membuatnya mudah dibaca (bahkan oleh orang yang tidak teknis). Ini dikenal sebagai pernyataan.

Ada banyak pernyataan RSpec yang berbeda dan kami tidak akan membahas detailnya, tetapi jangan ragu untuk meninjau dokumentasi untuk melihat semua fitur yang disediakan RSpec.

Membuat Pembantu untuk Pengujian Kami

Ada sejumlah pelat ketel yang diperlukan agar pengujian kami dapat berjalan. Dalam proyek ini, kami hanya memiliki satu file spesifikasi tetapi dalam proyek nyata Anda cenderung memiliki lusinan (tergantung pada ukuran aplikasi Anda).

Untuk membantu kami mengurangi kode boilerplate, kami akan meletakkannya di dalam file pembantu khusus yang akan kami muat dari file spesifikasi kami. File ini akan berjudul spec_helper.rb.

File ini akan melakukan beberapa hal:

  • beri tahu Ruby di mana kode aplikasi utama kami berada
  • muat kode aplikasi kami (agar pengujian tidak terjadi)
  • memuat pry gem (membantu kami men-debug kode kami; jika perlu).

Ini kodenya:

Catatan: baris pertama mungkin terlihat sedikit samar, jadi izinkan saya menjelaskan cara kerjanya. Di sini kami mengatakan kami ingin menambahkan folder / lib / ke variabel sistem $LOAD_PATH Ruby. Setiap kali Ruby mengevaluasi require'some_file' ia memiliki daftar direktori yang akan dicoba dan menemukan file itu. Dalam contoh ini, kami memastikan bahwa jika kami memiliki kode require 'example' bahwa Ruby akan dapat menemukannya karena akan memeriksa direktori / lib / kami dan di sana, ia akan menemukan file yang ditentukan. Ini adalah trik pintar yang akan Anda lihat digunakan di banyak permata Ruby, tetapi bisa sangat membingungkan jika Anda belum pernah melihatnya sebelumnya.

Kode Aplikasi

Kode aplikasi kami akan berada di dalam file berjudul example.rb.

Sebelum kita mulai menulis kode aplikasi apa pun, ingatlah bahwa kita sedang mengerjakan proyek TDD ini. Jadi kita akan membiarkan tes dalam file spesifikasi memandu kita tentang apa yang harus dilakukan terlebih dahulu.

Mari kita mulai dengan mengasumsikan Anda menggunakan guard untuk menjalankan tes Anda (jadi setiap kali kami membuat perubahan ke example.rb, Guard akan melihat perubahan dan melanjutkan untuk menjalankan example_spec.rb untuk memastikan pengujian kami lulus).

Bagi kami untuk melakukan TDD dengan benar, file example.rb kami akan kosong dan jadi jika kami membuka file dan 'menyimpannya' dalam keadaan saat ini, maka Guard akan berjalan dan kami akan menemukan (tidak mengejutkan) bahwa pengujian kami akan gagal:


Sekarang sebelum kita melangkah lebih jauh, izinkan saya mengklarifikasi lagi bahwa TDD didasarkan pada premis bahwa setiap baris kode ada alasannya, jadi jangan mulai berlomba dan menulis lebih banyak kode daripada yang Anda butuhkan. Hanya tulis jumlah kode minimum yang diperlukan untuk lulus tes. Bahkan jika kodenya jelek atau tidak memenuhi fungsionalitas penuh.

Titik TDD adalah memiliki loop umpan balik yang ketat, juga dikenal sebagai 'merah, hijau, refactor'). Apa artinya ini dalam praktik adalah:

  • tulis tes yang gagal
  • tulis jumlah kode paling sedikit agar bisa lulus
  • refactor kodenya

Anda akan segera melihat bahwa karena persyaratan kami sangat sederhana, kami tidak perlu melakukan refactor. Tetapi dalam proyek nyata dengan persyaratan yang jauh lebih kompleks, Anda mungkin perlu mengambil langkah ketiga dan memperbaiki kode yang Anda masukkan, agar tes lulus.


Kembali ke pengujian gagal kami, seperti yang Anda lihat dalam kesalahan, tidak ada kelas RSpecGreeter yang ditentukan. Mari kita perbaiki itu dan tambahkan kode berikut dan simpan file sehingga pengujian kami berjalan:

Ini akan menghasilkan kesalahan berikut:

Sekarang kita dapat melihat bahwa kesalahan ini memberi tahu kita bahwa metode greet tidak ada, jadi mari kita tambahkan dan simpan lagi file kita untuk menjalankan pengujian kita:

Oke, kita hampir sampai. Kesalahan yang kita dapatkan sekarang adalah:

RSpec memberi tahu kami bahwa mereka mengharapkan untuk melihat Hello RSpec! tetapi malah mendapat nil (karena kita mendefinisikan metode greet tetapi sebenarnya tidak mendefinisikan apa pun di dalam metode dan karenanya mengembalikan nil).

Kami akan menambahkan bagian kode yang tersisa yang akan melewati pengujian kami:

Itu dia, tes kelulusan:

Kami sudah selesai di sini. Tes kami ditulis dan kode dilewati.

Kesimpulan

Sejauh ini kami telah menerapkan proses Pengembangan Berbasis Tes untuk membangun aplikasi kami, di samping memanfaatkan kerangka pengujian RSpec yang populer.

Kami akan meninggalkannya di sini untuk saat ini. Kembali dan bergabunglah dengan kami untuk bagian dua di mana kita akan melihat lebih banyak fitur spesifik RSpec serta menggunakan permata Pry untuk membantu Anda men-debug dan menulis kode Anda.

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.