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

Pengujian RSpec untuk Pemula, Bagian 3

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

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

Dalam artikel terakhir tentang dasar-dasar RSpec, kami membahas beberapa bagian yang rapuh yang dapat Anda dan harus hindari, bagaimana Anda harus menyusun tes Anda, mengapa Anda harus menghindari database sebanyak mungkin, dan bagaimana mempercepat rangkaian uji Anda.

Topik

  • Uji kecepatan
  • Hambatan Database
  • Spring Preloader
  • Iffy RSpec Conveniences
  • Tamu Misteri
  • Kode Inline
  • Metode Extract

Sekarang setelah Anda memiliki dasar-dasar di bawah ikat pinggang Anda, kita harus meluangkan waktu untuk membahas beberapa bagian RSpec dan TDD yang meragukan—beberapa masalah yang dapat dengan mudah digunakan secara berlebihan dan beberapa kerugian menggunakan bagian dari DSL RSpec yang tidak direfleksikan. Saya ingin menghindari memasukkan banyak konsep lanjutan dalam otak TDD yang baru menetas, tetapi saya merasa beberapa poin perlu dibuat sebelum Anda melakukan pengujian pertama. Juga, menciptakan sebuah suite tes lambat karena kebiasaan buruk yang dengan mudah dapat dihindari adalah sesuatu yang Anda dapat meningkatkan sebagai pemula segera.

Tentu, ada beberapa hal yang Anda perlukan untuk mendapatkan lebih banyak pengalaman sebelum Anda merasa nyaman dan efektif dengan pengujian, tetapi saya yakin Anda juga akan merasa lebih baik dari awal jika Anda mengambil beberapa praktik terbaik yang akan meningkatkan spek berjenis tanpa terlalu banyak melebarkan keterampilan Anda sekarang. Ini juga merupakan jendela kecil ke dalam konsep yang lebih maju yang perlu Anda ambil dari waktu ke waktu untuk "menguasai" pengujian. Saya merasa bahwa saya seharusnya tidak terlalu mengganggumu di awal dengan ini karena mungkin saja terasa berbelit-belit dan membingungkan sebelum Anda mengembangkan gambaran yang lebih besar yang menghubungkan semuanya dengan rapi.

Uji kecepatan

Mari mulai dengan cepat. Sebuah suite cepat bukanlah apa-apa yang terjadi secara kebetulan; ini adalah masalah pemeliharaan "konstan". Mendengarkan tes Anda sangat sering sangat penting—setidaknya jika Anda bergabung dengan TDD dan telah meminum Kool-Aid untuk sementara waktu—dan suite tes cepat membuatnya jauh lebih masuk akal untuk memperhatikan di mana tes sedang membimbing. kamu.

Kecepatan uji adalah sesuatu yang harus Anda jaga dengan baik. Sangat penting untuk menguji kebiasaan rutin dan membuatnya tetap menyenangkan. Anda ingin dapat dengan cepat menjalankan tes Anda sehingga Anda mendapatkan umpan balik cepat saat Anda berkembang. Semakin lama waktu yang diperlukan untuk menjalankan rangkaian uji, semakin besar kemungkinan Anda melewatkan pengujian lebih banyak lagi sampai Anda hanya melakukannya di akhir sebelum Anda ingin mengirimkan fitur baru.

Itu mungkin tidak terdengar buruk pada awalnya, tapi ini bukan masalah sepele. Salah satu manfaat utama dari test suite adalah bahwa ia memandu desain aplikasi Anda—bagi saya ini mungkin adalah kemenangan terbesar dari TDD. Uji coba yang lebih lama membuat bagian ini sangat tidak mungkin karena sangat mungkin Anda tidak akan menjalankannya agar tidak merusak aliran Anda. Tes cepat menjamin bahwa Anda tidak memiliki alasan untuk tidak menjalankan tes Anda.

Anda dapat melihat proses ini sebagai dialog antara Anda dan rangkaian uji. Jika percakapan ini terlalu lambat, sungguh menyakitkan untuk melanjutkan. Ketika editor kode Anda menawarkan kemungkinan untuk juga menjalankan tes Anda, Anda pasti harus menggunakan fitur ini. Ini akan secara dramatis meningkatkan kecepatan dan meningkatkan alur kerja Anda. Berpindah setiap waktu antara editor dan cangkang untuk menjalankan tes Anda menjadi tua dengan sangat cepat. Namun karena artikel ini ditargetkan untuk pemrogram pemula, saya tidak mengharapkan Anda untuk menyiapkan alat Anda seperti ini sekarang juga. Ada cara lain yang dapat Anda lakukan untuk meningkatkan proses ini tanpa perlu mengotak-atik editor Anda segera. Sangat bagus untuk diketahui, dan saya menyarankan untuk menjadikan alat tersebut sebagai bagian dari alur kerja Anda.

Selain itu, perhatikan bahwa Anda sudah belajar cara mengiris tes dan Anda tidak perlu menjalankan rangkaian uji lengkap setiap saat. Anda dapat dengan mudah menjalankan file tunggal atau bahkan it tunggal membloknya—semua dalam editor kode yang mampu tanpa pernah meninggalkannya untuk terminal. Anda dapat memfokuskan tes pada jalur yang sedang diuji, misalnya. Itu terasa seperti sihir, jujur​—tidak pernah membosankan.

Hambatan Database

Menulis terlalu banyak ke basis data—seringkali sangat tidak perlu—adalah salah satu cara pasti untuk dengan cepat memperlambat rangkaian pengujian Anda secara signifikan. Dalam banyak skenario pengujian, Anda dapat memalsukan data yang Anda perlukan untuk membuat tes dan hanya fokus pada data yang langsung diuji. Anda tidak perlu memukul database untuk sebagian besar waktunya—terutama tidak untuk bagian yang tidak diuji secara langsung dan hanya mendukung pengujian, entah itu: pengguna yang masuk saat Anda menguji jumlah yang harus dibayar pada checkout, misalnya. Pengguna seperti tambahan yang bisa dipalsukan.

Anda harus mencoba melarikan diri dengan tidak memukul database sebanyak mungkin karena ini menggigit sepotong besar dari sebuah test suite yang lambat. Selain itu, cobalah untuk tidak menyiapkan terlalu banyak data jika Anda tidak memerlukannya sama sekali. Itu bisa sangat mudah untuk melupakan dengan tes integrasi khususnya. Tes unit sering lebih terfokus oleh definisi. Strategi ini akan terbukti sangat efektif dalam menghindari perlambatan test suite dari waktu ke waktu. Pilih dependensi Anda dengan sangat hati-hati dan lihat berapa jumlah data terkecil yang membuat tes Anda lolos.

Saya tidak ingin membahas lebih detail untuk saat ini—mungkin agak terlalu awal dalam lintasan Anda untuk berbicara tentang stub, mata-mata, pemalsuan, dan hal-hal lainnya. Membingungkan Anda di sini dengan konsep canggih seperti itu tampaknya kontraproduktif, dan Anda akan segera mengalami hal ini. Ada banyak strategi untuk tes cepat yang juga melibatkan alat lain selain RSpec. Untuk saat ini, cobalah untuk membungkus kepala Anda di sekitar gambar yang lebih besar dengan RSpec dan pengujian secara umum.

Anda juga ingin menguji semuanya hanya sekali—jika memungkinkan. Jangan menguji ulang hal yang sama berulang kali—itu hanya sia-sia. Ini kebanyakan terjadi karena kecelakaan dan/atau keputusan desain yang buruk. Jika Anda mulai memiliki tes yang lambat, ini adalah tempat yang mudah untuk refactor untuk mendapatkan dorongan kecepatan.

Mayoritas tes Anda juga harus berada di level Unit, menguji model Anda. Ini tidak hanya akan menjaga hal-hal yang cepat tetapi juga akan memberikan Anda bang terbesar untuk uang. Tes integrasi yang menguji seluruh alur kerja—meniru perilaku pengguna hingga tingkat tertentu dengan menyatukan sekumpulan komponen dan mengujinya secara bersamaan—harus menjadi bagian terkecil dari piramida pengujian Anda. Ini agak lambat dan "mahal". Mungkin 10% dari keseluruhan tes Anda tidak realistis untuk diambil—tetapi ini tergantung, saya kira.

Melatih database sesedikit mungkin bisa sulit karena Anda perlu mempelajari beberapa alat dan teknik untuk mencapai hal itu secara efektif, tetapi penting untuk mengembangkan rangkaian pengujian yang cukup cepat—cukup cepat untuk benar-benar menjalankan pengujian Anda secara rutin.

Spring Preloader

Server Spring adalah fitur Rails dan pramoad aplikasi Anda. Ini adalah strategi langsung lain untuk meningkatkan kecepatan tes Anda secara signifikan—langsung dari kotak, saya harus menambahkan. Apa yang dilakukannya adalah menjaga aplikasi Anda tetap berjalan di latar belakang tanpa perlu mem-boot-nya dengan setiap uji coba tunggal. Hal yang sama berlaku untuk tugas dan migrasi Rake; ini akan berjalan lebih cepat juga.

Karena Rails 4.1, Spring telah dimasukkan dalam Rails—ditambahkan ke Gemfile secara otomatis—dan Anda tidak perlu melakukan banyak hal untuk memulai atau menghentikan prapemuat ini. Di masa lalu kami harus memasang alat pilihan kami sendiri untuk ini—yang masih bisa Anda lakukan tentu saja jika Anda memiliki preferensi lain. Apa yang benar-benar bagus dan bijaksana adalah bahwa ini akan dimulai ulang secara otomatis jika Anda mengubah beberapa permata, inisialisasi atau file konfigurasi—sentuhan yang bagus dan berguna karena mudah lupa untuk mengurusnya sendiri.

Secara default dikonfigurasi untuk menjalankan perintah rails dan rake saja. Jadi kita perlu mengaturnya agar berjalan dengan perintah rspec untuk menjalankan pengujian kami. Anda dapat meminta status musim semi seperti:

Terminal

Output

Karena output mengatakan kepada kami bahwa Spring tidak berjalan, Anda cukup memulainya dengan spring server. Saat Anda sekarang menjalankan spring status, Anda akan melihat sesuatu yang mirip dengan ini:

Output

Sekarang kita harus memeriksa Spring apa yang diatur untuk preload.

Terminal

Output

Ini memberitahu kita bahwa Spring adalah Preloading Rails untuk perintah rake dan rails, dan tidak ada yang lain sejauh ini. Yang perlu kita urus. Kita perlu menambahkan permata musim semi-commands-rspec, dan tes kami kemudian siap untuk dimuat.

Gemfile

Terminal

Saya menghindarkan Anda output dari bundle install; Saya yakin Anda telah melihat lebih dari cukup pembagian Anda. Menjalankan bundle exec pegas binstub rspec, di sisi lain, menghasilkan file bin/rspec yang pada dasarnya menambahkannya untuk dimuat oleh Spring. Mari kita lihat apakah ini berfungsi:

Terminal

Ini menciptakan sesuatu yang disebut binstub — pembungkus untuk file yang dapat dieksekusi seperti rails, rake, bundel, rspec dan semacamnya—sehingga ketika Anda menggunakan perintah rspec, ia akan menggunakan Spring. Sebagai samping, binstubs seperti itu memastikan bahwa Anda menjalankan executable ini di lingkungan yang tepat. Mereka juga membiarkan Anda menjalankan perintah ini dari setiap direktori di aplikasi Anda—tidak hanya dari root. Keuntungan lain dari binstubs adalah bahwa Anda tidak perlu menambahkan bundel exec dengan segala sesuatu.

Output

Terlihat A-OK! Mari berhenti dan mulai ulang server Spring sebelum kita melanjutkan:

Terminal

Jadi sekarang Anda menjalankan server musim semi dalam satu jendela terminal khusus, dan Anda menjalankan pengujian Anda dengan sintaks yang sedikit berbeda di yang lain. Kita hanya perlu melakukan awalan setiap uji coba dengan perintah spring:

Terminal

Ini menjalankan semua file spesifikasi Anda, tentu saja. Tetapi tidak perlu berhenti di situ. Anda juga dapat menjalankan file tunggal atau tes yang ditandai melalui Spring—tidak masalah! Dan mereka semua akan secepat kilat sekarang; pada ruang uji yang lebih kecil mereka benar-benar tampak nyaris seketika. Di atas itu, Anda dapat menggunakan sintaks yang sama untuk perintah rails dan rake Anda. Bagus, ya?

Terminal

Jadi, kita mendapatkan Spring out of the box untuk mempercepat pekerjaan di Rails, tetapi kita tidak boleh lupa untuk menambahkan Permata kecil ini untuk membiarkan Spring tahu cara bermain bola dengan RSpec.

Iffy RSpec Conveniences

Hal-hal yang disebutkan di bagian ini mungkin baik untuk dihindari selama Anda dapat menemukan solusi lain untuk mereka. Terlalu banyak menggunakan beberapa kenyamanan RSpec dapat menyebabkan berkembangnya kebiasaan pengujian yang buruk—setidaknya yang paling meragukan. Apa yang akan kita bahas di sini adalah nyaman di permukaan tetapi mungkin menggigit Anda sedikit kemudian di jalan.

Mereka seharusnya tidak dianggap sebagai AntiPattern—hal-hal yang harus dihindari dengan segera—tetapi lebih dilihat sebagai 'bau', hal-hal yang harus Anda waspadai dan yang mungkin memperkenalkan biaya signifikan yang sering kali tidak ingin Anda bayarkan. Alasan untuk hal ini melibatkan beberapa ide dan konsep yang Anda sebagai pemula mungkin belum terbiasa—dan sejujurnya mungkin sedikit berlebihan di kepala Anda saat ini—tetapi setidaknya saya harus mengirim Anda pulang dengan beberapa bendera merah untuk memikirkan dan berkomitmen untuk memori untuk saat ini.

  • let

Memiliki banyak referensi let dapat tampak sangat nyaman pada awalnya—terutama karena mereka DRY hal-hal yang cukup sedikit. Sepertinya ekstraksi yang cukup bagus pada awalnya memiliki mereka di bagian atas file Anda, misalnya. Di sisi lain, mereka dapat dengan mudah memberi Anda kesulitan memahami kode Anda sendiri jika Anda mengunjungi tes tertentu beberapa waktu kemudian. Tidak memiliki pengaturan data dalam let block Anda tidak membantu pemahaman tes Anda terlalu banyak. Itu tidak sepele seperti yang mungkin terdengar pada awalnya, terutama jika pengembang lain yang terlibat yang perlu membaca pekerjaan Anda juga.

Kebingungan semacam ini menjadi jauh lebih mahal karena semakin banyak pengembang yang terlibat. Tidak hanya memakan waktu jika Anda harus memburu let referensi berulang-ulang, itu juga bodoh karena itu akan dapat dihindari dengan sedikit usaha. Kejelasan adalah raja, tidak diragukan lagi. Argumen lain untuk menjaga inline data ini adalah bahwa rangkaian pengujian Anda akan kurang rapuh. Anda tidak ingin membangun rumah kartu yang menjadi lebih tidak stabil dengan setiap let yang menyembunyikan detail dari setiap tes. Anda mungkin belajar bahwa menggunakan variabel global bukanlah ide yang bagus. Dalam arti itu, let adalah semi-global dalam file spesifikasi Anda.

Masalah lainnya adalah Anda perlu menguji banyak variasi yang berbeda, negara bagian yang berbeda untuk skenario serupa. Anda akan segera kehabisan pernyataan let yang beralasan untuk mencakup semua versi yang berbeda yang mungkin Anda butuhkan—atau berakhir dengan tumpukan jerami ton variasi status yang sama namanya. Bila Anda mengatur data dalam setiap tes langsung, Anda tidak memiliki masalah itu. Variabel lokal murah, sangat mudah dibaca, dan jangan main-main dengan cakupan lainnya. Pada kenyataannya, mereka dapat menjadi lebih ekspresif karena Anda tidak perlu mempertimbangkan ton tes lain yang mungkin memiliki masalah dengan nama tertentu. Anda ingin menghindari membuat lain DSL di atas kerangka kerja yang semua orang perlu memecahkan untuk setiap tes yang menggunakan let. Saya berharap yang terasa sangat banyak seperti membuang-buang waktu semua orang.

  • before & after

Simpan hal-hal seperti before, after dan variasinya untuk acara-acara khusus dan jangan menggunakannya sepanjang waktu, di semua tempat. Melihatnya sebagai salah satu senjata besar yang Anda keluarkan untuk hal-hal meta. Membersihkan data Anda adalah contoh yang baik yang terlalu meta untuk setiap tes individu untuk berurusan dengan. Anda ingin ekstrak yang, tentu saja.

Tamu Misteri

Seringkali Anda meletakkan barang let di bagian atas file dan menyembunyikan detail ini dari tes lain yang menggunakannya untuk menurunkan file. Anda ingin memiliki informasi dan data yang relevan sedekat mungkin dengan bagian di mana Anda benar-benar melakukan tes—tidak jauh dari membuat tes individual menjadi lebih tidak jelas.

Pada akhirnya, rasanya seperti terlalu banyak tali untuk digantung, karena let kita kenalkan perlengkapan bersama secara luas. Yang pada dasarnya memecah data dummy uji yang lingkupnya lebih tidak cukup ketat.

Hal ini mudah menyebabkan satu bau besar yang disebut "tamu misteri". Itu berarti bahwa Anda memiliki data pengujian yang muncul entah dari mana atau hanya menjadi diasumsikan. Anda akan sering perlu untuk memburu mereka pertama untuk memahami tes—terutama jika beberapa waktu telah berlalu sejak Anda menulis kode atau jika Anda baru untuk basis kode. Jauh lebih efektif untuk menentukan data uji Anda tepat di mana Anda membutuhkannya—dalam pengaturan tes tertentu dan tidak dalam lingkup yang lebih luas.

Agent Spec

Ketika Anda melihat ini, itu terbaca dengan baik, kan? Ringkas, satu-liner, cukup bersih, bukan? Mari jangan membodohi diri sendiri. Tes ini tidak memberi tahu kita banyak tentang agent yang dipermasalahkan, dan itu tidak memberi tahu kita keseluruhan cerita. Detail penerapannya penting, tetapi kami tidak melihat semuanya. Agen tersebut tampaknya telah dibuat di tempat lain, dan kami harus memburunya terlebih dahulu untuk memahami sepenuhnya apa yang terjadi di sini. Jadi mungkin terlihat elegan di permukaan, tetapi itu datang dengan harga yang lumayan.

Ya, pengujian Anda mungkin tidak akan menjadi super DRY sepanjang waktu dalam hal itu, tetapi ini adalah harga kecil yang harus dibayar karena lebih ekspresif dan lebih mudah dipahami, saya kira. Tentu ada pengecualian, tetapi mereka harus benar-benar diterapkan pada keadaan luar biasa setelah Anda kehabisan opsi yang ditawarkan Ruby murni.

Dengan tamu misterius, Anda harus mencari tahu dari mana data berasal, mengapa itu penting, dan apa spesifikasinya sebenarnya. Tidak melihat rincian penerapan dalam tes tertentu itu sendiri hanya membuat hidup Anda lebih sulit daripada yang seharusnya. Maksud saya, lakukan apa yang Anda rasakan jika Anda mengerjakan proyek Anda sendiri, tetapi ketika pengembang lain terlibat, akan lebih baik untuk berpikir tentang membuat pengalaman mereka dengan kode Anda semulus mungkin.

Seperti banyak hal, tentu saja, hal-hal yang penting terletak pada detailnya, dan Anda tidak ingin menyembunyikan diri dan orang lain dalam kegelapan tentang hal-hal itu. Keterbacaan, kesederhanaan dan kenyamanan let tidak perlu mengorbankan kejelasan atas rincian pelaksanaan dan penyesatan. Anda ingin setiap tes individu untuk menceritakan kisah lengkap dan memberikan semua konteks untuk memahaminya dengan segera.

Kode Inline

Singkat cerita, Anda ingin memiliki tes yang mudah dibaca dan lebih mudah ditebak—berdasarkan uji-demi-uji. Coba tentukan semua yang Anda butuhkan dalam tes yang sebenarnya—dan tidak lebih dari itu. Sampah seperti ini mulai “berbau” seperti sampah lainnya. Itu juga menyiratkan bahwa Anda harus menambahkan detail yang Anda perlukan untuk pengujian tertentu selambat mungkin—ketika Anda membuat data uji secara keseluruhan, dalam skenario yang sebenarnya dan bukan beberapa tempat yang jauh. Penggunaan yang disarankan dari let menawarkan berbagai jenis kenyamanan yang tampaknya menentang ide ini.

Mari kita lanjutkan lagi dengan contoh sebelumnya dan menerapkannya tanpa masalah tamu misterius. Dalam solusi di bawah ini, kami akan menemukan semua info yang relevan untuk inline tes. Kami dapat tetap berada di spesifikasi ini jika gagal dan tidak perlu mencari info tambahan di tempat lain.

Agent Spec

Akan lebih baik jika let Anda mengatur data uji barebone yang dapat Anda tingkatkan berdasarkan kebutuhan untuk mengetahui dalam setiap tes khusus, tetapi ini bukan cara let bergulir. Begitulah cara kami menggunakan pabrik melalui Factory Girl hari ini.

Saya akan menghindarkan Anda detailnya, terutama karena saya sudah menulis beberapa bagian tentang itu. Berikut adalah artikel saya yang dirancang untuk pemula 101 dan 201 tentang apa yang ditawarkan Factory Girl—jika Anda sudah ingin tahu tentang itu. Ini ditulis untuk pengembang tanpa banyak pengalaman juga.

Mari kita lihat contoh sederhana lain yang memanfaatkan data pengujian pendukung yang disiapkan secara inline:

Agent Spec

Seperti yang Anda lihat, kami memiliki semua informasi yang diperlukan tes ini di satu tempat dan tidak perlu mencari informasi spesifik apa pun di tempat lain. Ia menceritakan sebuah cerita dan tidak jelas. Seperti disebutkan, ini bukanlah strategi terbaik untuk kode DRY. Pembayarannya baik, meskipun. Kejelasan dan pembacaan melebihi ini sedikit kode yang berulang-ulang oleh tembakan panjang—terutama di besar codebases.

Misalnya, Anda menulis beberapa fitur baru, tampaknya tidak terkait, dan tiba-tiba tes ini mulai gagal sebagai jaminan kerusakan dan Anda belum menyentuh file spesifikasi ini di usia.

Apakah Anda pikir Anda akan bahagia jika Anda perlu untuk menguraikan komponen setup pertama untuk memahami dan memperbaiki gagal tes ini sebelum Anda dapat melanjutkan dengan fitur yang sama sekali berbeda yang sedang Anda kerjakan? Saya kira tidak! Anda ingin keluar dari spec "tidak terkait" ini secepat mungkin dan mendapatkan kembali untuk menyelesaikan fitur yang lain.

Bila Anda menemukan semua data uji yang ada di sana di mana tes Anda memberitahu Anda mana ia gagal, Anda meningkatkan kesempatan Anda oleh tembakan panjang untuk memperbaiki ini dengan cepat tanpa "Download" bagian yang benar-benar berbeda dari aplikasi ke otak Anda.

Metode Extract

Anda dapat bersih dan kode DRY Anda secara signifikan dengan menulis metode penolong Anda sendiri. Ada tidak perlu menggunakan RSpec DSL untuk sesuatu yang murah sebagai metode Ruby.

Katakanlah Anda menemukan beberapa perlengkapan berulang yang mulai merasa agak kotor. Daripada pergi dengan let atau subject, tentukan metode di bagian bawah blok mendeskripsikan—sebuah konvensi—dan ekstrak persamaan ke dalamnya. Jika digunakan sedikit lebih luas dalam file, Anda dapat meletakkannya di bagian bawah file juga.

Efek samping yang bagus adalah Anda tidak berurusan dengan variabel semi-global seperti itu. Anda juga akan menyelamatkan diri Anda dari membuat banyak perubahan di semua tempat jika Anda perlu mengubah sedikit data. Anda sekarang dapat pergi ke satu tempat utama di mana metode tersebut didefinisikan dan mempengaruhi semua tempat yang digunakan sekaligus. Tidak buruk!

Agent Spec

Seperti yang Anda lihat, ada sedikit kode pengaturan berulang, dan kami ingin menghindari penulisan ini berulang kali. Sebaliknya, kami hanya ingin melihat hal-hal penting untuk tes ini dan memiliki metode membangun sisa objek untuk kami.

Agent Spec

Sekarang metode kami diekstrak menangani section dan licence_to_kill barang dan dengan demikian tidak mengalihkan perhatian kita dari hal-hal penting dari tes. Tentu saja, ini adalah contoh tiruan, tetapi Anda dapat mengukur kerumitannya sebanyak yang Anda butuhkan. Strategi tidak berubah. Ini adalah teknik refactoring yang sangat sederhana—itulah mengapa saya memperkenalkan ini sejak awal—tetapi salah satu yang paling efektif. Juga, itu hampir tidak perlu otak untuk menghindari alat ekstraksi yang ditawarkan RSpecs.

Yang juga harus Anda perhatikan adalah seberapa ekspresif metode penolong ini tanpa membayar harga ekstra.

Pikiran Akhir

Menghindari beberapa bagian dari DSL RSpec dan memanfaatkan baik prinsip-prinsip Ruby dan Pemrograman Berorientasi Objek yang baik adalah cara yang baik untuk mendekati penulisan tes Anda. Anda dapat dengan bebas menggunakan hal-hal penting, describecontext dan it, tentu saja.

Menemukan alasan yang baik untuk menggunakan bagian lain dari RSpec dan menghindari mereka selama Anda bisa. Hanya karena hal-hal tampak nyaman dan mewah bukan alasan yang cukup bagus untuk menggunakannya—lebih baik untuk menjaga agar hal-hal lebih sederhana.

Sederhana itu bagus; itu membuat tes Anda sehat dan cepat.

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.