Pengujian RSpec untuk Pemula, Bagian 1

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

Apakah Anda baru di Rails? Baru coding? Penasaran dengan RSpec dan bagaimana Anda dapat memulai pengujian? Jika demikian, artikel ini harus menjadi titik awal yang baik bagi Anda untuk mendapatkan ke dalam pembangunan berbasis tes. Ini akan menjelaskan kepada Anda mengapa dan bagaimana, dan itu akan memberi Anda survival kit untuk pergi pada foya pengujian pertama Anda.

Topik

Apa Gunanya?
RSpec?
Persiapan
Menjalankan Tes
Sintaks Dasar
Empat Fase Tes
Hal yang Sulit Tentang Pengujian

Apa Gunanya?

Apa RSpec baik untuk? RSpec ini sangat berguna di tingkat Unit Test, pengujian rincian yang lebih halus dan logika bisnis aplikasi Anda. Itu berarti pengujian internal seperti model dan controller dari aplikasi Anda. Tes yang mencakup pandangan Anda atau tes fitur yang mensimulasikan arus pengguna lebih lengkap, seperti pembelian item, tidak akan fokus yang RSpec dibuat untuk. RSpec tidak membuat penggunaan sopir web—seperti Kapibara tidak, misalnya—yang mensimulasikan interaksi pengguna dengan situs sebenarnya atau representasi dari itu.

Pembangunan berbasis tes (TDD), apa gunanya? Yah, itu tidak mudah untuk menjawab tanpa makan Anda beberapa klise. Saya harap ini tidak terdengar mengelak. Aku bisa memberikan jawaban yang cepat, tapi saya ingin menghindari pengiriman Anda rumah lapar setelah hanya makanan kecil. Hasil dari seri ini sedikit tentang RSpec dan pengujian harus tidak hanya memberikan semua info untuk menjawab pertanyaan ini diri Anda sendiri tetapi juga menyediakan Anda dengan alat dan pemahaman untuk memulai dengan pengujian sementara merasa agak yakin sudah tentang pengujian hal.

Pemula tampaknya memiliki waktu sulit memperoleh ke dalam RSpec dan alur kerja TDD daripada mulai mendapatkan berbahaya dengan Ruby atau Rails. Kenapa bisa begitu? Saya hanya bisa menebak saat ini, tetapi di satu sisi, literatur tampaknya sebagian besar berfokus pada orang-orang yang sudah memiliki beberapa keterampilan pemrograman di bawah ikat pinggang mereka, dan di sisi lain, belajar semua hal yang terlibat untuk memiliki pemahaman yang jelas adalah sedikit menakutkan. Kurva belajar dapat cukup curam, saya kira. Untuk pengujian efektif, ada banyak bagian yang bergerak yang terlibat. Sangat banyak untuk meminta untuk pemula yang baru saja mulai untuk memahami kerangka seperti rel untuk melihat proses membangun aplikasi dari perspektif lawan dan belajar API yang sama sekali baru untuk menulis kode untuk kode Anda.

Aku berpikir tentang cara pendekatan ini "dilema" untuk generasi berikutnya dari coders yang hanya mencari untuk memulai halus ke seluruh hal ini. Ini adalah apa yang saya datang dengan. Aku akan meruntuhkan sintaks yang paling penting untuk Anda tanpa mengambil lebih dari dasar pengetahuan tentang Ruby dan sedikit rel. Daripada menutupi setiap sudut mungkin dan membingungkan Anda mati, kita akan pergi ke kit kelangsungan hidup dasar Anda dan mencoba untuk melukis gambar yang lebih besar. Kita akan membahas "Bagaimana?" agak verbosely di agar tidak kehilangan baru coders sepanjang jalan. Bagian kedua dari persamaan akan menjelaskan "Mengapa?"

If I am beruntung, Anda akan bisa pergi dengan dasar yang baik untuk buku-buku yang lebih maju sementara merasa yakin tentang gambar yang lebih besar. Ok sekarang, mari kita berjalan jalan!

Manfaat dan semacamnya

Mari kita kembali untuk tujuan pengujian. Pengujian berguna untuk menulis aplikasi kualitas yang lebih baik? Nah, ini dapat hangat diperdebatkan, tetapi pada saat saya akan menjawab pertanyaan ini dengan ya—saya di kamp hipster TDD, kurasa. Mari kita lihat mengapa tes menyediakan aplikasi Anda dengan beberapa manfaat yang sulit untuk mengabaikan:

Mereka memeriksa jika fungsi pekerjaan Anda sebagai dimaksudkan. Terus-menerus memvalidasi bahwa Anda menulis kode karya penting untuk kesehatan aplikasi Anda dan tim Anda kewarasan.

Mereka menguji hal-hal yang Anda tidak ingin menguji dengan tangan, cek membosankan yang dapat Anda lakukan dengan tangan—terutama ketika Anda akan perlu untuk memeriksa ini sepanjang waktu. Anda ingin menjadi sebagai yakin sebagai kemungkinan bahwa fungsi baru Anda atau kelas baru Anda atau apa pun tidak menimbulkan efek samping pada mungkin benar-benar tak terduga bidang aplikasi Anda. Mengotomatisasi hal semacam itu tidak hanya menghemat waktu satu ton, tetapi juga akan membuat skenario pengujian konsisten dan direproduksi. Itu saja membuat mereka jauh lebih bisa diandalkan daripada rawan kesalahan pengujian dengan tangan.

Kami ingin memastikan bahwa aplikasi berperilaku dengan cara tertentu, dengan cara yang diharapkan. Tes dapat memastikan tingkat cukup tinggi yang cara pengguna berinteraksi dengan aplikasi Anda berfungsi dan menghindari skenario bug yang Anda mampu untuk meramalkan. Tes memeriksa bahwa aplikasi Anda bekerja dengan cara yang Anda rancang—dan terus bekerja setelah Anda memperkenalkan modifikasi. Hal ini terutama penting ketika suite tes Anda memberitahu Anda tentang gagal skenario tentang implementasi aplikasi Anda yang mungkin menjadi tua dan oleh karena itu tidak persis di belakang otak Anda lagi dan tidak dipertimbangkan ketika Anda memperkenalkan beberapa fungsi baru. Singkatnya, ini membantu untuk menjaga aplikasi Anda sehat dan menghindari memperkenalkan ton bug.

Mengotomatisasi tes membuat Anda benar-benar menguji lebih sering. Bayangkan jika Anda harus menguji sesuatu untuk waktu 40 untuk beberapa alasan. Jika hanya memakan waktu sedikit, seberapa mudahnya untuk bosan dan melewatkan proses sama sekali? Hal-hal semacam ini adalah langkah pertama di lereng licin di mana Anda dapat mencium persentase yang layak dari cakupan kode selamat tinggal.

Tes berfungsi sebagai dokumentasi. Hah? Spesifikasi yang Anda tulis memberi orang lain titik balik cepat kepada tim Anda untuk mempelajari basis kode baru dan memahami apa yang seharusnya dilakukan. Menulis kode Anda di RSpec, misalnya, sangat ekspresif dan membentuk blok kode yang sangat mudah dibaca yang menceritakan sebuah kisah jika dilakukan dengan benar. Karena dapat ditulis sangat deskriptif sementara juga menjadi Domain Specific Language (DSL) yang sangat ringkas, RSpec memukul dua burung dengan satu batu: tidak sedang menggunakan verbose dalam API-nya dan memberi Anda semua sarana untuk menulis skenario pengujian yang sangat mudah dimengerti. Itulah yang selalu saya sukai dan mengapa saya tidak pernah benar-benar hangat dengan Cucumber, yang memecahkan masalah yang sama dengan cara yang terlalu ramah klien, saya kira.

Mereka dapat meminimalkan jumlah kode yang Anda tulis. Alih-alih berputar-putar seperti orang gila, mencoba hal-hal yang lebih bebas, praktik mengemudi tes kode Anda memungkinkan Anda hanya menulis kode yang diperlukan untuk lulus tes. Tidak ada kode kelebihan. Hal yang sering Anda dengar dalam karir masa depan Anda adalah kode yang terbaik adalah kode yang tidak harus Anda tulis atau sesuatu. Mengapa? Yah, paling sering, solusi yang lebih elegan melibatkan jumlah yang lebih rendah kode dan juga, kode yang Anda tidak menulis—yang mungkin tidak perlu—tidak akan menyebabkan bug masa depan dan tidak perlu dipertahankan. Jadi menulis tes pertama, sebelum Anda menulis implementasi, memberikan fokus yang jelas pada masalah yang Anda butuhkan untuk memecahkan berikutnya. Menulis hanya kode yang diperlukan, dan tidak sengaja, adalah mungkin meremehkan efek samping yang TDD dapat menyediakan Anda dengan.

Mereka memiliki efek positif pada desain Anda. Bagi saya, memahami bagian ini menyalakan lampu dan membuat saya benar-benar menghargai hal seluruh pengujian. Ketika Anda menulis Anda implementasi di sekitar skenario pengujian sangat terfokus, kode Anda kemungkinan akan berubah untuk menjadi lebih compartmentalized dan modular. Karena kita semua teman-teman kering—"Jangan ulangi dirimu sendiri!"—dan sebagai sedikit kopling antara komponen dalam aplikasi Anda sebanyak mungkin, ini adalah disiplin yang sederhana namun efektif untuk mencapai sistem yang dirancang baik dari tanah up. Aspek ini adalah manfaat yang paling penting, saya pikir. Ya, yang lain juga cukup mengagumkan, tetapi ketika tes juga mengakibatkan apps yang kualitas lebih baik karena desain halus, saya akan mengatakan Jackpot!

Itu bermuara pada uang juga. Bila Anda memiliki aplikasi yang stabil yang mudah untuk mempertahankan dan mudah untuk mengubah, Anda akan menghemat cukup banyak uang dalam jangka panjang. Kerumitan yang tidak bisa menghantui proyek dengan mudah, dan motivasi tidak akan pada puncaknya ketika tim Anda harus melawan kode Anda karena rapuh dan dirancang buruk. Desain aplikasi yang baik benar-benar dapat mendukung tujuan bisnis Anda—dan sebaliknya. Apakah Anda ingin memperkenalkan beberapa fitur baru yang sangat penting untuk bisnis Anda, tetapi Anda terus-menerus melawan arsitektur Anda karena dibangun di atas pasir? Tentu saja tidak, dan kita semua telah melihat banyak contoh bisnis yang dengan cepat menghilang karena alasan itu. Kebiasaan pengujian yang baik dapat menjadi garis pertahanan yang efektif untuk situasi semacam itu.

Tujuan lain yang penting adalah dalam hal kualitas kode Anda sendiri. Perangkat lunak Anda menulis harus mudah dimengerti untuk para pengembang lainnya—sebanyak mungkin, setidaknya. Tes Anda benar-benar dapat membantu menyampaikan fungsi dan maksud aplikasi Anda—dan tidak hanya kepada anggota lain dalam tim tetapi juga untuk diri Anda di masa depan. Jika Anda tidak menyentuh bagian tertentu dari kode Anda selama beberapa waktu, itu benar-benar akan berguna untuk menyegarkan ingatan Anda dari bagaimana dan mengapa Anda menulis perangkat lunak dengan dokumentasi yang menyediakan alat seperti RSpec—dan RSpec Apakah ini benar-benar baik , sangat benar-benar.

Karena kode Anda akan selalu berubah, refactoring kode Anda akan dan harus selalu menjadi bagian dari pengembangan perangkat lunak Anda. Dan karena perubahan jadi panggang ke dalam proses ini, Anda perlu untuk memastikan bahwa perubahan ini tidak menghasilkan efek samping yang tak terduga di tempat-tempat yang mengejutkan. Tes suite memberikan Anda keamanan sangat ketat-merajut bersih untuk merasa lebih nyaman dan bebas untuk refactor dengan penuh semangat. Aspek ini, di samping manfaat desain TDD dapat memberi Anda, adalah manfaat favorit saya, sebuah test suite dapat membantu Anda. Memodifikasi dan memperluas kode Anda adalah seperti komponen penting dari inovasi-inovasi Anda sudah dirilis "Produk" bahwa Anda perlu alat yang memberikan Anda kebebasan sebanyak mungkin dengan proses itu. Saya tidak yakin apakah orang yang kritis dalam menulis rangkaian uji ekstensif sangat peduli dengan aspek ini.

Anda akan memiliki peluang bagus untuk membangun hal-hal baru lebih cepat di tahap selanjutnya karena umpan balik dari test suite akan memberi Anda umpan balik tentang kegagalan, bug, dan keterbatasan Anda—tentu saja jauh lebih cepat daripada yang bisa dilakukan oleh manusia. Plus, itu akan memberi Anda kepercayaan bekerja dengan jaring keamanan yang menjadi lebih berharga semakin lama Anda pergi.

Di aplikasi Anda, terutama jika mereka telah tumbuh secara signifikan, Anda ingin dapat mempercayai perangkat lunak Anda. 100% kode cakupan terdengar jauh lebih manis ketika Anda memiliki situs yang adalah beberapa tahun dan tersentuh oleh ratusan pengembang. Mampu mempercayai kode baru yang Anda perkenalkan dan membangun di atasnya adalah salah satu blis dari pengembangan perangkat lunak yang tidak dapat dibeli uang nantinya.

Persiapan

Terminal

1	rails new your_app -T

-T memungkinkan Anda melewatkan Unit pengujian, kerangka pengujian yang datang dengan Rails.

Gemfile

1	group :development, :test do
2	gem 'rspec-rails'
3	end

Terminal

bundle

Setelah itu kita perlu menjalankan generator yang datang dengan RSpec:

Terminal

1	rails generate rspec:install

Output

1	create .rspec
2	create spec
3	create spec/spec_helper.rb
4	create spec/rails_helper.rb

Apa yang dilakukan adalah mengatur struktur dasar untuk tes RSpec Anda dalam Rails. Seperti yang Anda lihat dari hasil di atas, generator diinisialisasi spec direktori dengan beberapa file yang akan Anda butuhkan kemudian. .rspec adalah file konfigurasi yang tidak perlu kita memanipulasi untuk sekarang. Aku hanya ingin membiarkan Anda tahu apa yang Anda miliki di depan Anda. File lain cukup jelas, tapi saya ingin menyebutkan perbedaan mereka.

spec_helper.rb adalah untuk spesifikasi yang tidak bergantung pada Rails.
rails_helper.rb, di sisi lain, adalah untuk spesifikasi yang bergantung padanya.

Apa itu tidak jelas adalah bahwa salah satu dari file-file ini harus diminta di atas file Anda spec (tes file) untuk menjalankan tes Anda. Mari kita memiliki sekilas! Ketika Anda menghasilkan model melalui:

Terminal

1	rails generate model dummy_model name:string

Output

invoke  active_record
create    db/migrate/20160521004127_create_dummy_models.rb
create    app/models/dummy_model.rb
invoke    rspec
create    spec/models/dummy_model_spec.rb

Tidak hanya akan Rails telah menciptakan _spec.rb terkait yang file untuk Anda, spesifikasi Anda juga secara otomatis punya require 'rails_helper' secara default di atas file spesifikasi Anda. Itu berarti Anda sudah siap untuk pergi, segera.

spec/models/dummy_model_spec.rb

1	require 'rails_helper'
2
3	...

Jadi dengan konfigurasi ini, Anda dapat menguji Rails app, model Anda misalnya, dan RSpec tidak mendapatkan bingung tentang kelas model yang digunakan dalam Rails. Hal ini diperlukan untuk meminta setiap kali Anda memerlukan hal-hal seperti ActiveRecord, ApplicationController dan sebagainya. Jadi ini adalah skenario normal Anda dan oleh karena itu harus menjadi pilihan logis pertama sebagai pemula.

Membutuhkan spec_helper.rb, di sisi lain, akan melemparkan kesalahan jika Anda menulis tes yang menyertakan logika bisnis dari aplikasi Rails Anda. Dalam skenario itu, RSpec tidak akan tahu apa yang Anda bicarakan ketika Anda ingin menguji beberapa rel model, misalnya.

Jadi cerita super pendek, spec_helper tidak memuat rel-hanya itu! Tentu saja, Anda dapat pergi liar dengan konfigurasi, tetapi ini adalah apa-apa yang saya ingin Anda menjadi prihatin tentang sekarang. Mari kita fokus pada dasar-dasar, bagaimana untuk menjalankan tes dan sintaks. Yang harus cukup untuk pemula. Mari kita lanjutkan!

Menjalankan tes

Anda siap untuk menjalankan tes Anda. RSpec membutuhkan file tes Anda untuk memiliki akhiran tertentu seperti _spec untuk memahami file mana untuk menjalankan. Jika Anda menggunakan generator, hal ini tidak menjadi perhatian, tetapi jika Anda ingin menulis file tes sendiri, ini adalah bagaimana mereka perlu mengakhiri. Jadi Anda harus meletakkan file seperti your_first_test_spec.rb di direktori spec Anda.

Menggunakan generator untuk membuat dummy model sudah memberikan kita dengan spec/models/dummy_model_spec.rb. Tidak buruk! Satu hal yang tersisa untuk dilakukan sebelum tes siap:

Terminal

1	rake db:migrate
2	rake db:test:prepare

Perintah ini menjalankan migrasi untuk boneka model kami dihasilkan di atas, dan set up database tes dengan model juga. Sekarang kita benar-benar menjalankan tes:

Terminal

rake

Perintah rake akan dijalankan semua tes, tes lengkap suite. Biasanya Anda harus menggunakan perintah ini ketika Anda selesai beberapa fitur dan ingin latihan tes seluruh suite.

Output

*
Pending: (Failures listed here are expected and do not affect your suite's status)

1) DummyModel add some examples to (or delete) /Users/vis_kid/projects/rspec-test-app/rspec-dummy/spec/models/dummy_model_spec.rb
   # Not yet implemented
   # ./spec/models/dummy_model_spec.rb:4

Finished in 0.00083 seconds (files took 1.94 seconds to load)

1 example, 0 failures, 1 pending

Selamat! Anda hanya berlari pengujian RSpec pertama. Tidak seburuk itu, kan? Tentu saja, ini adalah tes dummy untuk saat ini—dengan kode uji coba yang dihasilkan oleh Rails. Versi yang lebih terfokus untuk menjalankan tes Anda—Anda sebenarnya memiliki lebih banyak opsi daripada itu—adalah menjalankan file individual, misalnya. Seperti ini:

Terminal

1	bundle exec rspec spec/models/dummy_model_spec.rb

Ini hanya akan menjalankan tes file bukan tes seluruh suite. Dengan aplikasi yang lebih besar yang bergantung pada jumlah tinggi berkas test, ini akan menjadi real time saver. Tapi dalam hal menyimpan waktu dan tes kekhususan, ini hanya menggaruk permukaan, jujur. Saya pikir kita akan membahas lebih lanjut tentang bagaimana untuk mencukur sejumlah besar waktu pengujian dalam artikel ketiga dalam seri ini. Mari kita lihat seberapa jauh kita mendapatkan!

Cara lain untuk latihan tes seluruh suite adalah dengan hanya menjalankan rspec—dengan atau tanpa bundel exec, tergantung pada konfigurasi Anda.

Terminal

1	bundle exec rspec

Satu hal lagi yang harus saya sebutkan sebelum kita melanjutkan, Anda juga dapat menjalankan hanya beberapa bagian tertentu dari tes. Katakanlah Anda hanya ingin menjalankan semua tes Anda untuk Anda model kode:

Terminal

1	bundle exec rspec spec/models

Semudah itu!

Sintaks Dasar

Saya menyarankan bahwa kita mulai dengan dasar-dasar telanjang dan melihat ke dalam beberapa pilihan lain yang menyediakan RSpec dalam dua artikel berikutnya. Mari kita lihat struktur dasar dari ujian dan menyelam ke perairan yang lebih maju ketika kita punya satu ini keluar dari jalan.

describe

Ini akan menjadi roti dan mentega karena dapat mengatur spesifikasi Anda. Anda dapat referensi string atau kelas sendiri:

Beberapa Spec

describe User do

end

describe 'Some string' do

end

Bagian describe adalah blok bangunan dasar untuk mengatur tes Anda ke dalam kelompok logis, koheren untuk menguji. Pada dasarnya, ruang lingkup untuk berbagai bagian aplikasi Anda yang ingin Anda uji.

Beberapa Spec

describe User do
  ...
end

describe Guest do
  ...
end

describe Attacker do
  ...
end

Tip yang bagus adalah untuk memperketat cakupan Anda lebih jauh lagi. Karena beberapa kelas akan tumbuh cukup signifikan, bukanlah ide yang bagus untuk memiliki semua metode yang ingin Anda uji untuk satu kelas dalam satu blok describe tunggal. Anda dapat membuat beberapa blok ini, tentu saja, dan memfokuskannya di sekitar metode instance atau kelas sebagai gantinya. Untuk membuat maksud Anda lebih jelas, yang Anda butuhkan adalah memberikan nama kelas dengan string tambahan yang merujuk ke metode yang ingin Anda uji.

Beberapa Spec

describe Agent, '#favorite_gadget' do
  ...
end

describe Agent, '#favorite_gun' do
  ...
end

describe Agent, '.gambler' do
  ...
end

Dengan cara itu Anda mendapatkan yang terbaik dari kedua dunia. Anda merangkum pengujian terkait dalam kelompok perwakilan mereka sambil tetap berfokus pada hal-hal dan pada ukuran yang layak. Untuk pengguna sangat baru untuk tanah Ruby, saya harus menyebutkan bahwa # hanya untuk referensi contoh metode sementara dot . disediakan untuk metode kelas. Karena mereka berada di dalam string, mereka memiliki implikasi teknis tidak ada di sini, tetapi mereka sinyal niat Anda untuk pengembang lain dan diri Anda masa depan. Jangan lupa tanda titik setelah nama kelas—itu tidak akan berhasil tanpa itu! Dalam satu menit, ketika kita mendapatkan untuk expect, aku akan menunjukkan kepada Anda mengapa pendekatan ini super nyaman.

it

Dalam lingkup kelompok describe, kami menggunakan ruang lingkup lain blok it. Ini dibuat untuk contoh aktual di bawah ujian. Jika Anda ingin menguji contoh metode #favorite_gadget pada kelas Agent, itu akan terlihat seperti ini:

Beberapa Spec

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
    ...
  end

end

String yang Anda berikan untuk it menghalangi pekerjaan sebagai dokumentasi utama untuk menguji. Di dalamnya, Anda menentukan persis apa jenis perilaku yang Anda ingin atau setiap dari metode tersebut. Rekomendasi saya adalah untuk tidak pergi ke laut dan menjadi terlalu bertele-tele tentang hal itu tetapi pada saat yang sama untuk tidak menjadi terlalu samar dan membingungkan orang lain dengan deskripsi terlalu pintar.

Pikirkan tentang apa yang terkecil dan paling sederhana pelaksanaan ini bagian dari teka-teki bisa dan harus mencapai. Semakin baik Anda menulis bagian ini, yang lebih baik secara keseluruhan dokumentasi untuk app Anda akan. Jangan terburu-buru bagian ini karena hanya string yang tidak melakukan kerusakan—setidaknya tidak di permukaan.

expect()

Sekarang kita sudah lebih ke jantung hal. Metode ini memungkinkan Anda memverifikasi atau memalsukan bagian dari sistem Anda ingin menguji. Mari kita kembali ke contoh kami sebelumnya dan melihatnya beraksi (terbatas):

Beberapa Spec

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
    expect(agent.favorite_gadget).to eq 'Walther PPK' 
  end

end

expect() adalah "baru" pernyataan sintaks RSpec. Sebelumnya kami menggunakan should sebaliknya. Cerita yang berbeda, tapi saya ingin menyebutkan ini dalam kasus Anda menjalankan ke dalamnya. expect() mengharapkan bahwa Anda menyediakan objek dan latihan apapun metode yang diuji di atasnya. Akhirnya, Anda menulis hasil menegaskan di sisi kanan.

Anda memiliki pilihan untuk pergi rute yang positif atau negatif dengan .to eq atau .not_to eq misalnya (eq menjadi pendek untuk sama tentu saja). Anda selalu dapat beralih logika di sekitar—apa pun setelan terbaik kebutuhan Anda. Mari kita menjalankan tes ini tidak masuk akal dan fokus pada output yang kita punya sebagai hasil dari tes setup:

Terminal

1	rspec spec/models/agent_spec.rb

Output

1	Failures:
2
3	1) Agent#favorite_gadget returns one item, the favorite gadget of the agent
4	Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'

Cukup bagus, bukan? **"Agen#favorite_gadget kembali satu item, dan menampilkan gadget favorit agen"** memberitahu Anda semua yang perlu Anda ketahui:

kelas terlibat
metode di bawah ujian
hasil yang diharapkan

Jika kami telah Tinggalkan string yang menggambarkan metode dalam blok describe, maka output akan menjadi jauh lebih jelas dan mudah dibaca:

Beberapa Spec

describe Agent do

  it 'returns one item, the favorite gadget of the agent ' do
    expect(agent.favorite_gadget).to eq 'Walther PPK' 
  end

end

Output

1	Failures:
2
3	1) Agent returns one item, the favorite gadget of the agent
4	Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'

Tentu saja, ada cara lain untuk menghindari dan berurusan dengan ini—melewati info ini melalui block it Anda, misalnya—tapi pendekatan lain hanya sederhana dan bekerja. Apa pun yang membuat aliran darah Anda, tentu!

Empat Fase Tes

Praktik terbaik dalam pengujian merekomendasikan agar kami menyusun pengujian kami dalam empat fase berbeda:

pengaturan tes
latihan tes
uji verifikasi
uji teardown

Empat tahap ini adalah sebagian besar untuk dibaca dan memberikan Anda tes struktur yang konvensional. Itu adalah apa yang disebut pengujian pola, pada dasarnya, sebuah praktik yang masyarakat secara luas disetujui untuk menjadi berguna dan direkomendasikan. Topik pola ini seluruh lubang kelinci mendalam, jadi tahu bahwa aku akan meninggalkan keluar banyak sehingga tidak untuk membingungkan pemula antara kamu mati.

Mempersiapkan

Selama setup, Anda mempersiapkan skenario di mana tes seharusnya untuk menjalankan. Dalam kebanyakan kasus, ini akan mencakup data yang diperlukan untuk siap untuk beberapa jenis latihan. Sedikit tip: Jangan overcomplicate hal-hal, dan mengatur hanya jumlah minimum yang diperlukan untuk membuat tes bekerja.

1	agent = Agent.create(name: 'James Bond')
2	mission = Mission.create(name: 'Moonraker', status: 'Briefed')

Latihan

Bagian ini benar-benar berjalan satu hal yang Anda ingin menguji spec ini. Dapat yang sederhana seperti:

1	status = mission.agent_status

Memverifikasi

Sekarang Anda memverifikasi jika Anda pernyataan tentang tes yang bertemu atau tidak. Jadi Anda menguji sistem terhadap harapan Anda sendiri.

1	expect(status).not_to eq 'MIA')

Teardown

Kerangka mengurus memori dan membersihkan masalah database—a reset, pada dasarnya. Tidak ada bagi Anda untuk menangani saat ini. Tujuannya adalah untuk mendapatkan kembali keadaan murni untuk menjalankan tes baru tanpa kejutan dari yang sedang berjalan. Mari kita lihat apa ini berarti dalam sebuah contoh dummy:

Beberapa Spec

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
  # Setup
    agent = Agent.create(name: 'James Bond')
    q = Quartermaster.create(name: 'Q') 
    q.technical_briefing(agent)

  # Exercise    
    favorite_gadget = agent.favorite_gadget
  
  # Verify
    expect(favorite_gadget).to eq 'Walther PPK' 

  # Teardown is for now mostly handled by RSpec itself
  end

end

Seperti yang Anda lihat, dalam contoh ini kita dipisahkan latihan dan memverifikasi fase jelas dari satu sama lain, sementara di lain dummy contoh di atas, expect(agent.favorite_gadget).to eq 'Walther PKK, kami dicampur fase kedua bersama-sama. Keduanya berlaku skenario dan memiliki tempat mereka. Juga, garis baru membantu untuk memisahkan secara visual bagaimana tes terstruktur.

Hal yang sulit tentang pengujian

Sekarang datang bagian yang sulit, pengujian dan bagaimana. Menurut pendapat saya, ini adalah aspek pengujian yang paling membingungkan bagi pendatang baru—dan dimengerti! Anda baru bahasa dan kerangka dan seringkali bahkan tidak tahu belum apa yang Anda tidak tahu. Bagaimana Anda menulis tes untuk itu? Pertanyaan yang sangat bagus.

Aku akan sangat terang, Anda tidak—kemungkinan—dan Anda tidak akan cukup lama. Mendapatkan nyaman dengan hal ini memakan waktu beberapa saat. Ketika Anda memiliki seorang mentor atau menghadiri beberapa kamp dan semacamnya, Anda memiliki kesempatan untuk belajar langsung dari orang-orang yang berpengalaman. Dalam hal ini, kemajuan Anda dalam Departemen ini akan berbeda, tentu saja.

Di sisi lain, jika—seperti banyak orang lain luar sana—Anda mengajar diri sendiri hal-hal ini, kesabaran akan menjadi kunci. Membaca semua buku dan artikel tentu membuat Anda berada pada arah yang benar, tetapi saya pikir pengujian membutuhkan banyak potongan teka-teki yang lebih canggih agar Anda dapat memahami dan, mungkin bahkan lebih penting, sebelum Anda merasa nyaman dengannya. .

Berita "baik" adalah bahwa hal ini tidak biasa dan kita semua yang telah ada. Ketekunan penting. Anda dapat melakukan ini, hal ini tidak roket sains, tetapi itu akan memakan waktu lama sampai Anda dapat menulis aplikasi secara efektif dari sebaliknya—dari sudut pandang tes, maksudku. Untuk saat ini, terus mendorong, bersenang-senang, membuat kesalahan, menulis apps, menyalin tutorial dan entah apa lagi, sampai lampu pergi.

Akhir Pikiran

Ketika Anda menulis tes individu Anda, Anda ingin membuat benda-benda mereka melakukan hal yang paling sederhana mungkin untuk mencapai tujuan Anda—sangat terfokus tes benar-benar penting. Anda ingin merancang aplikasi Anda melalui langkah-langkah yang sangat sederhana dan kemudian ikuti kesalahan yang diberikan oleh suite uji Anda.

Hanya implementasikan apa yang diperlukan untuk mendapatkan aplikasi berwarna hijau. Tidak lebih, tidak kurang! Itu adalah bagian "driven" dalam pengembangan yang digerakkan oleh pengujian. Pekerjaan Anda dipandu oleh kebutuhan tes Anda.