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

Pengujian RSpec untuk Pemula, Bagian 2

by
Length:LongLanguages:
This post is part of a series called RSpec Testing for Beginners.
RSpec Testing for Beginners, Part 1
RSpec Testing for Beginners, Part 3

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

Artikel kedua dalam seri singkat ini mengajarkan Anda bagaimana menggunakan berbagai penanding yang datang dengan RSpec. Ia juga menunjukkan Anda bagaimana untuk mengiris suite tes Anda melalui penandaan, bagaimana callback bekerja, dan bagaimana untuk mengambil beberapa data. Kami memperluas sedikit kit kelangsungan hidup dasar dari artikel pertama dan menunjukkan Anda cukup untuk menjadi berbahaya tanpa terlalu banyak tali menggantung diri.

Topik

  • Matchers
  • Let
  • Subjects
  • Callbacks
  • Generators
  • Tags

Dalam artikel pertama kami menghabiskan cukup banyak waktu untuk mencoba menjawab "Mengapa?" pengujian. Saya sarankan kami mendapatkan kembali ke "bagaimana?" dan spare diri konteks lain. Kita menutupi bagian secara ekstensif sudah. Mari kita lihat apa RSpec lain yang ditawarkan bahwa Anda sebagai pemula dapat menangani segera.

Matchers

Jadi ini akan mendekati hati banyak hal. RSpec menyediakan Anda dengan satu ton disebut matchers. Ini adalah roti dan mentega ketika Anda menulis harapan Anda. Sejauh ini Anda telah melihat .to eq and .not_to eq. Tapi ada banyak gudang besar untuk menulis spesifikasi Anda. Anda dapat menguji untuk meningkatkan kesalahan, untuk truthy dan falsy nilai-nilai, atau bahkan kelas khusus. Mari kita berjalan turun beberapa pilihan untuk Anda mulai:

  • .to eq
  • .not_to eq

Tes ini untuk kesetaraan.

Beberapa Spec

Perhatian!

Untuk menjaga hal-hal yang singkat, aku makan dua mengharapkan pernyataan dalam satu blok it. Ini adalah praktik yang baik, meskipun, untuk menguji hanya satu hal per tes. Ini membuat hal-hal yang jauh lebih terfokus, dan tes Anda akan berakhir rapuh kurang ketika Anda mengubah hal-hal.

  • .to be_truthy
  • .to be true

Beberapa Spec

Perbedaannya adalah be_truthy yang benar saat itu bukan nil atau false. Jadi itu akan berlalu jika hasilnya tidak dua—semacam "true-like". .to be true di sisi lain hanya menerima nilai true dan tidak ada yang lain.

  • .to be_falsy
  • .to be false

Beberapa Spec

Mirip dengan dua contoh di atas, .to be_falsy mengharapkan false atau nilai nil, dan .to be false akan hanya melakukan perbandingan langsung pada false.

  • .to be_nil
  • .to_not be_nil

Dan terakhir tetapi tidak paling, tes ini tepat untuk nil itu sendiri. Aku cadangan Anda contoh.

  • .to match()

Saya harap Anda sudah memiliki kesenangan melihat ke dalam ekspresi reguler. Jika tidak, ini adalah urutan karakter dengan yang Anda dapat menentukan sebuah pola yang Anda meletakkan antara dua garis miring maju untuk mencari string. Sebuah regex bisa sangat berguna jika Anda ingin mencari pola yang lebih luas yang dapat Anda generalisasi dalam ekspresi seperti itu.

Beberapa Spec

Misalkan kita berhadapan dengan agen seperti James Bond, 007, yang ditetapkan nomor tiga-digit. Kemudian kita bisa tes untuk itu dengan cara ini—primitively di sini, tentu saja.

  • >
  • <
  • <=
  • >=

Perbandingan berguna lebih sering daripada satu mungkin berpikir. Saya menganggap contoh di bawah akan mencakup apa yang perlu Anda ketahui.

Beberapa Spec

Sekarang, kita semakin kurang membosankan. Anda juga bisa menguji kelas dan jenis:

  • .to be_an_instance_of
  • .to be_a
  • .to be_an

Beberapa Spec

Dalam contoh boneka di atas, Anda dapat melihat daftar agen-agen yang berkaitan dengan misi yang bukan kelas Agent tetapi ActiveRecord::Associations::CollectionProxy. Apa yang harus Anda ambil dari yang satu ini adalah bahwa kita dapat dengan mudah menguji untuk kelas sendiri sementara tinggal sangat ekspresif. .to be_a dan .to be_an melakukan satu dan hal yang sama. Anda memiliki kedua opsi yang tersedia untuk membuat semuanya dapat dibaca.

Pengujian untuk kesalahan ini juga secara besar-besaran nyaman di RSpec. Jika Anda super segar untuk rel dan tidak yakin namun kesalahan yang bisa melempar kerangka kerja Anda, Anda mungkin tidak merasa perlu untuk menggunakan ini—tentu saja, yang membuat total akal. Pada tahap berikutnya dalam pengembangan Anda, Anda akan menemukan mereka sangat berguna, meskipun. Anda memiliki empat cara untuk berurusan dengan mereka:

  • .to raise_error

Ini adalah cara yang paling umum. Kesalahan apa pun yang dibangkitkan akan dilemparkan bersih Anda.

  • .to raise_error(ErrorClass)

Dengan cara itu Anda dapat menentukan persis yang kelas kesalahan harus berasal dari.

  • .to raise_error(ErrorClass, "Some error message")

Hal ini bahkan lebih baik berkurai karena Anda tidak hanya menyebutkan kelas kesalahan tetapi pesan tertentu yang harus dibuang dengan kesalahan.

  • .to raise_error("Some error message)

Atau Anda hanya menyebutkan pesan kesalahan itu sendiri tanpa kesalahan kelas. Bagian expect perlu ditulis sedikit berbeda, meskipun—kita perlu untuk membungkus bagian bawah teks di sebuah blok kode itu sendiri:

Beberapa Spec

  • .to start_with
  • .to end_with

Karena kita sering berurusan dengan koleksi ketika membangun aplikasi web, it's nice untuk memiliki alat untuk mengintip ke mereka. Di sini kami menambahkan dua agen, Q dan James Bond, dan hanya ingin tahu yang datang pertama dan terakhir dalam koleksi agen untuk misi khusus—Moonraker di sini.

Beberapa Spec Agent

  • .to include

Yang satu ini juga berguna untuk memeriksa isi dari koleksi.

Beberapa Spec Agent

  • predikat matchers

Matchers predikat ini adalah fitur dari RSpec untuk secara dinamis membuat matchers untuk Anda. Jika Anda memiliki predikat metode dalam model Anda, misalnya (berakhir dengan tanda tanya), kemudian RSpec tahu bahwa harus membangun matchers bagi Anda yang dapat Anda gunakan dalam tes Anda. Dalam contoh di bawah ini, kami ingin menguji apakah agen James Bond:

Agent Model

Sekarang, kita dapat menggunakan ini dalam spesifikasi kami seperti:

Beberapa Spec Agent

RSpec Mari kita menggunakan metode nama tanpa tanda tanya—untuk membentuk sintaks yang lebih baik, kurasa. Keren, bukan?

Let

let dan let! mungkin terlihat seperti variabel pada awalnya, tetapi mereka sebenarnya adalah metode penolong. Yang pertama secara malas dievaluasi, yang berarti hanya berjalan dan dievaluasi ketika spec benar-benar menggunakannya, dan yang lainnya dibiarkan dengan bang(!) Dijalankan tanpa digunakan oleh spec atau tidak. Kedua versi tersebut dimafikan, dan nilainya akan di-cache dalam lingkup contoh yang sama.

Beberapa File Spec

Versi bang yang tidak malas dievaluasi dapat memakan waktu dan karena itu mahal jika ia menjadi teman baru mewah. Mengapa? Karena akan mengatur data ini untuk setiap tes dalam pertanyaan, apa pun, dan mungkin akhirnya berakhir menjadi salah satu dari hal-hal buruk yang memperlambat suite tes Anda secara signifikan.

Anda harus tahu fitur ini RSpec karena let banyak dikenal dan digunakan. Bahwa menjadi kata, artikel berikutnya akan menunjukkan kepada Anda beberapa masalah dengan yang Anda harus menyadari. Menggunakan metode penolong ini dengan hati-hati, atau setidaknya di dosis kecil untuk sekarang.

Subjects

RSpec menawarkan kemampuan untuk menyatakan subjek di bawah tes sangat eksplisit. Ada solusi yang lebih baik untuk ini, dan kita akan membahas kerugian dari pendekatan ini dalam artikel berikutnya ketika saya menunjukkan beberapa hal yang biasanya Anda ingin menghindari. Tetapi untuk sekarang, mari kita lihat subject apa yang bisa lakukan untuk Anda:

Beberapa File Spec

Pendekatan ini dapat, di satu sisi, membantu Anda untuk mengurangi duplikasi kode, memiliki protagonis menyatakan sekali dalam lingkup tertentu, tapi dapat juga menyebabkan sesuatu yang disebut tamu misteri. Ini berarti bahwa kita mungkin berakhir dalam situasi di mana kami menggunakan data untuk salah satu skenario pengujian kami tetapi tidak tahu lagi di mana itu benar-benar berasal dari dan apa itu terdiri dari. Lebih lanjut tentang itu di artikel selanjutnya.

Callbacks

Jika Anda belum mengetahui callback, izinkan saya memberi Anda pengarahan singkat. Callback dijalankan pada titik spesifik tertentu dalam siklus hidup kode. Dalam hal Rails, ini berarti Anda memiliki kode yang sedang dijalankan sebelum objek dibuat, diperbarui, dihancurkan, dll.

Dalam konteks RSpec, ini adalah siklus uji yang sedang dijalankan. Itu berarti Anda dapat menentukan kait yang harus dijalankan sebelum atau sesudah setiap pengujian dijalankan dalam file spesifikasi, misalnya—atau hanya sekitar setiap pengujian. Ada beberapa opsi lebih halus yang tersedia, tetapi saya menyarankan agar kami tidak sampai tersesat dalam detail untuk saat ini. Hal pertama yang pertama:

  • before(:each)

Callback ini dijalankan sebelum setiap contoh pengujian.

Beberapa File Spec

Katakanlah Anda membutuhkan gadget tertentu untuk setiap pengujian yang Anda jalankan dalam cakupan tertentu. before memungkinkan Anda mengekstrak ini menjadi sebuah blok dan menyiapkan potongan kecil ini untuk Anda dengan nyaman. Ketika Anda mengatur data dengan cara itu, Anda harus menggunakan variabel instan, tentu saja, untuk mengaksesnya di antara berbagai cakupan.

Perhatian!

Jangan tertipu oleh kemudahan dalam contoh ini. Hanya karena Anda dapat melakukan hal semacam ini bukan berarti Anda harus melakukannya. Saya ingin menghindari masuk ke wilayah AntiPattern dan membingungkan Anda, tetapi di sisi lain, saya ingin menjelaskan kelemahan untuk latihan boneka sederhana ini sedikit juga.

Dalam contoh di atas, akan jauh lebih ekspresif jika Anda mengatur objek yang diperlukan berdasarkan uji-demi-uji. Khususnya pada file spesifikasi yang lebih besar, Anda dapat dengan cepat melupakan koneksi kecil ini dan menyulitkan orang lain untuk mengumpulkan teka-teki ini.

  • before(:all)

blok before ini hanya berjalan satu kali sebelum semua contoh lain dalam file spesifikasi.

Beberapa File Spec

Ketika Anda mengingat empat fase pengujian, before memblok kadang-kadang sangat membantu dalam mengatur sesuatu untuk Anda yang perlu diulang secara rutin—mungkin hal-hal yang sedikit lebih bersifat meta.

after(:each) dan after(:all) memiliki perilaku yang sama tetapi hanya berjalan setelah tes Anda dijalankan. after sering digunakan untuk membersihkan file Anda, misalnya. Tetapi saya pikir itu terlalu dini untuk membahasnya. Jadi, ajaklah ke memori, ketahuilah bahwa itu ada jika Anda mulai membutuhkannya, dan mari kita lanjutkan untuk menjelajahi hal-hal lain yang lebih mendasar.

Semua callback ini dapat ditempatkan secara strategis agar sesuai dengan kebutuhan Anda. Tempatkan mereka dalam lingkup describe apa pun yang Anda perlukan untuk menjalankannya—mereka tidak harus selalu ditempatkan di atas file spek Anda. Mereka dapat dengan mudah ditumpuk di dalam spesifikasi Anda.

Beberapa File Spec

Seperti yang dapat Anda amati, Anda dapat menempatkan blok callback pada ruang lingkup apa pun sesuai keinginan Anda, dan masuk sedalam yang Anda butuhkan. Kode dalam callback akan dieksekusi dalam lingkup lingkup blok yang dijelaskan. Tetapi sedikit saran: jika Anda merasa perlu bersarang terlalu banyak dan hal-hal menjadi sedikit berantakan dan rumit, pikirkan kembali pendekatan Anda dan pertimbangkan bagaimana Anda dapat menyederhanakan tes dan pengaturannya. KISS! Buat itu sederhana, bodoh. Selain itu, perhatikan seberapa baik hal ini dibaca saat kami memaksa pengujian ini gagal:

Output

Generators

Mari kita lihat sekilas apa generator yang disediakan oleh RSpec untuk Anda. Anda telah melihat satu ketika kami menggunakan rails generate rspec:install. Ini kawan kecil membuat pengaturan RSpec bagi kita cepat dan mudah. Apa lagi yang kita punya?

  • rspec:model

Ingin memiliki spesifikasi model dummy lain?

Terminal

Output

Cepat, kan? Atau spesifikasi baru untuk tes pengontrol, misalnya:

  • rspec:controller

Terminal

Output

  • rspec:view

Sama bekerja untuk pemandangan, tentu saja. Kami tidak akan menguji setiap pandangan seperti itu, meskipun. Spesifikasi untuk pemandangan memberikan paling bang untuk uang, dan benar-benar cukup dalam mungkin hampir setiap skenario untuk tidak langsung menguji pandangan Anda melalui fitur tes.

Fitur tes tidak khas RSpec per se dan lebih cocok untuk artikel lain. Itu dikatakan, jika Anda ingin tahu, periksa Capybara, yang merupakan alat yang sangat baik untuk hal semacam itu. Ini memungkinkan Anda menguji seluruh alur yang menjalankan beberapa bagian aplikasi Anda bersama-sama—menguji fitur lengkap saat mensimulasikan pengalaman browser. Sebagai contoh, pengguna yang membayar untuk beberapa item dalam keranjang belanja.

  • rspec:helper

Strategi generator yang sama memungkinkan kita juga menempatkan seorang penolong tanpa banyak rewel.

Terminal

Output

Bagian helper_helper ganda itu tidak kecelakaan. Ketika kita memberikannya nama "bermakna" lebih, Anda akan melihat bahwa RSpec hanya menempel _helper sendiri.

Terminal

Output

Sepatah Kata Tentang Pembantu

Tidak, direktori ini tidak adalah tempat untuk menimbun metode penolong berharga Anda yang muncul saat refactoring tes Anda. Ini akan pergi di bawah spec/support, sebenarnya. spec/helpers adalah untuk tes yang Anda harus menulis untuk Anda lihat pembantu-pembantu seperti set_date akan menjadi contoh yang umum. Ya, cakupan uji lengkap dari kode Anda juga harus mencakup metode penolong ini. Hanya karena mereka sering terlihat kecil dan sepele tidak berarti bahwa kita harus mengabaikan mereka atau mengabaikan potensi mereka untuk bug yang ingin kita tangkap. Semakin kompleks pembantu sebenarnya, semakin banyak alasan Anda harus menulis helper_spec untuk itu!

Seandainya Anda mulai bermain-main dengan segera, perlu diingat bahwa Anda perlu menjalankan metode helper Anda pada objek helper ketika Anda menulis tes penolong Anda untuk bekerja. Jadi mereka hanya bisa diekspos menggunakan objek ini. Sesuatu seperti ini:

Some Helper Spec

Anda dapat menggunakan jenis generator yang sama untuk spesifikasi fitur, spesifikasi integrasi, dan spesifikasi mailer. Ini di luar jangkauan kami untuk hari ini, tetapi Anda dapat menyerahkannya ke memori untuk penggunaan di masa mendatang:

  • rspec:mailer
  • rspec:feature
  • rspec:integration

A Look at Generated Specs

Spesifikasi yang kami buat melalui generator di atas siap digunakan, dan Anda dapat menambahkan pengujian Anda di sana segera. Mari kita lihat sekilas perbedaan antara spesifikasi, meskipun:

spec/models/dummy_model_spec.rb

spec/controllers/dummy_controller_controller_spec.rb

spec/helpers/dummy_helper_helper_spec.rb

Tidak perlu seorang wunderkind untuk mengetahui bahwa mereka semua memiliki tipe yang berbeda. Ini :type metadata RSpec memberi Anda kesempatan untuk mengiris dan mengadu tes Anda di seluruh struktur file. Anda dapat menargetkan tes ini sedikit lebih baik dengan cara itu. Katakanlah Anda ingin memiliki semacam pembantu hanya dimuat untuk spesifikasi pengontrol, misalnya. Contoh lain adalah Anda ingin menggunakan struktur direktori lain untuk spesifikasi yang tidak diharapkan oleh RSpec. Memiliki metadata ini dalam pengujian Anda memungkinkan untuk terus menggunakan fungsi dukungan RSpec dan tidak menjadwalkan uji coba. Jadi Anda bebas menggunakan struktur direktori apa pun yang bekerja untuk Anda jika Anda menambahkan metadata :type ini.

Tes RSpec standar Anda tidak bergantung pada metadata itu, di sisi lain. Saat Anda menggunakan generator ini, mereka akan ditambahkan secara gratis, tetapi Anda benar-benar dapat menghindarinya juga jika Anda tidak membutuhkannya.

Anda juga dapat menggunakan metadata ini untuk memfilter spesifikasi Anda. Katakanlah Anda memiliki blok sebelumnya yang seharusnya hanya berjalan pada spesifikasi model, misalnya. Rapi! Untuk rangkaian uji yang lebih besar, ini mungkin akan sangat berguna suatu hari nanti. Anda dapat memfilter grup fokus mana yang ingin Anda jalankan—alih-alih mengeksekusi seluruh rangkaian, yang mungkin memakan waktu cukup lama.

Opsi Anda melampaui opsi tiga pemberian tag di atas, tentu saja. Mari pelajari lebih lanjut tentang mengiris dan memotong tes Anda di bagian selanjutnya.

Tags

Saat Anda mengumpulkan rangkaian pengujian yang lebih besar dari waktu ke waktu, itu tidak akan cukup untuk menjalankan pengujian di folder tertentu untuk menjalankan pengujian RSpec dengan cepat dan efisien. Apa yang Anda ingin dapat lakukan adalah menjalankan tes yang termasuk bersama-sama tetapi mungkin tersebar di beberapa direktori. Memberi tag untuk menyelamatkan! Jangan salah paham, mengatur pengujian Anda dengan cerdas di folder Anda juga merupakan kunci, tetapi pemberian tag hanya membutuhkan sedikit lebih jauh.

Anda memberi Anda tes metadata beberapa simbol seperti ":wip",":checkout", atau apa pun sesuai dengan kebutuhan Anda. Ketika Anda menjalankan kelompok-kelompok tes terfokus ini, Anda cukup menentukan bahwa RSpec harus mengabaikan menjalankan tes lain kali ini dengan memberikan bendera dengan nama tag.

Beberapa File Spec

Terminal

Output

Anda juga bisa menjalankan semua jenis pengujian dan mengabaikan sekelompok grup yang ditandai dengan cara tertentu. Anda cukup memberikan tilde (~) di depan nama tag, dan RSpec senang untuk mengabaikan tes ini.

Terminal

Menjalankan banyak tag secara bersamaan juga bukan masalah:

Terminal

Seperti yang dapat Anda lihat di atas, Anda dapat mencampur dan mencocokkan mereka sesuai keinginan. Sintaks ini tidak sempurna—mengulangi --tag mungkin tidak ideal—tapi hei, itu tidak ada masalah besar baik! Ya, semua ini adalah pekerjaan yang lebih ekstra dan overhead mental ketika Anda menyusun spesifikasi, tetapi di sisi lain, itu benar-benar memberi Anda kemampuan yang kuat untuk mengiris suite uji sesuai permintaan. Pada proyek yang lebih besar, itu dapat menghemat banyak waktu seperti itu.

Pikiran Akhir

Apa yang telah Anda pelajari sejauh ini harus membekali Anda dengan dasar-dasar mutlak untuk bermain dengan tes sendiri—kit survival untuk pemula. Dan benar-benar bermain dan membuat kesalahan sebanyak yang Anda bisa. Ambil RSpec dan seluruh thingie yang digerakkan oleh pengujian untuk mendapatkan giliran, dan jangan berharap untuk segera menulis pengujian kualitas. Masih ada beberapa bagian yang hilang sebelum Anda akan merasa nyaman dan sebelum Anda akan efektif dengannya.

Bagi saya, ini sedikit mengecewakan pada awalnya karena sulit untuk melihat cara menguji sesuatu ketika saya belum menerapkannya dan tidak sepenuhnya memahami bagaimana hal itu akan terjadi.

Pengujian benar-benar membuktikan apakah Anda memahami kerangka kerja seperti Rails dan mengetahui bagaimana bagian-bagiannya cocok bersama. Ketika Anda menulis tes, Anda harus mampu menulis harapan untuk bagaimana suatu kerangka kerja harus berperilaku.

Itu tidak mudah jika Anda baru memulai dengan semua ini. Berurusan dengan beberapa bahasa spesifik domain—di sini RSpec dan Rails, misalnya—ditambah mempelajari Ruby API dapat membingungkan sekali. Jangan merasa buruk jika kurva pembelajaran tampak menakutkan; itu akan lebih mudah jika Anda mematuhinya. Membuat bola lampu ini padam tidak akan terjadi malam hari, tetapi bagi saya, itu sangat berharga.

Advertisement
Advertisement
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.