Kapan menggunakan RSpec let ()?

Saya cenderung menggunakan sebelum blok untuk mengatur variabel contoh. Saya kemudian menggunakan variabel-variabel tersebut di seluruh contoh saya. Saya baru-baru ini datang let(). Menurut dokumen RSpec, sudah biasa

... untuk menentukan metode pembantu memoized. Nilai akan di-cache di beberapa panggilan dalam contoh yang sama tetapi tidak di seluruh contoh.

Bagaimana ini berbeda dari menggunakan variabel instan di sebelum blok? Dan juga kapan Anda harus menggunakan let()vs before()?

Saya selalu lebih suka letvariabel instan karena beberapa alasan:

• Variabel instance muncul saat direferensikan. Ini berarti bahwa jika Anda mengeja ejaan variabel instan, yang baru akan dibuat dan diinisialisasi nil, yang dapat menyebabkan bug halus dan positif palsu. Karena letmembuat metode, Anda akan mendapatkan NameErrorketika Anda salah mengeja, yang menurut saya lebih disukai. Itu membuatnya lebih mudah untuk refactor spesifikasi juga.
• Sebuah before(:each)kait akan dijalankan sebelum setiap contoh, bahkan jika contoh tersebut tidak menggunakan variabel instan apa pun yang ditentukan dalam hook. Ini biasanya bukan masalah besar, tetapi jika setup variabel instan membutuhkan waktu lama, maka Anda membuang-buang siklus. Untuk metode yang ditentukan oleh let, kode inisialisasi hanya berjalan jika contoh memanggilnya.
• Anda bisa refactor dari variabel lokal dalam contoh langsung menjadi let tanpa mengubah sintaks referensi dalam contoh. Jika Anda refactor ke variabel instan, Anda harus mengubah cara Anda mereferensikan objek dalam contoh (misalnya menambahkan sebuah @).
• Ini agak subyektif, tetapi seperti yang ditunjukkan Mike Lewis, saya pikir itu membuat spec lebih mudah dibaca. Saya suka organisasi mendefinisikan semua objek dependen saya dengan letdan menjaga itblok saya bagus dan pendek.

Tautan terkait dapat ditemukan di sini: http://www.betterspecs.org/#let

Perbedaan antara menggunakan contoh variabel dan let()bahwa let()adalah malas-dievaluasi . Ini berarti bahwa let()tidak dievaluasi sampai metode yang ditetapkan dijalankan untuk pertama kalinya.

Perbedaan antara beforedan letadalah yang let()memberi Anda cara yang bagus untuk mendefinisikan sekelompok variabel dalam gaya 'cascading'. Dengan melakukan ini, spek terlihat sedikit lebih baik dengan menyederhanakan kode.

Saya telah sepenuhnya mengganti semua penggunaan variabel instan dalam tes rspec saya untuk menggunakan let (). Saya telah menulis contoh kilat untuk seorang teman yang menggunakannya untuk mengajar kelas Rspec kecil: http://ruby-lambda.blogspot.com/2011/02/agile-rspec-with-let.html

Seperti beberapa jawaban lain di sini mengatakan, biarkan () malas dievaluasi sehingga hanya akan memuat yang membutuhkan pemuatan. Ini KERING spesifikasi dan membuatnya lebih mudah dibaca. Sebenarnya saya telah mem-porting kode let () Rspec untuk digunakan di controller saya, dengan style permata inherited_resource. http://ruby-lambda.blogspot.com/2010/06/stealing-let-from-rspec.html

Bersamaan dengan evaluasi malas, keuntungan lainnya adalah, dikombinasikan dengan ActiveSupport :: Concern, dan spec-support-behavior / load-everything-in, Anda dapat membuat spec mini-DSL Anda sendiri yang spesifik untuk aplikasi Anda. Saya sudah menulis yang untuk menguji terhadap sumber daya Rack dan RESTful.

Strategi yang saya gunakan adalah Factory-everything (via Machinist + Forgery / Faker). Namun, dimungkinkan untuk menggunakannya dalam kombinasi dengan sebelum (: masing-masing) blok untuk memuat pabrik ke seluruh set kelompok contoh, memungkinkan spesifikasi berjalan lebih cepat: http://makandra.com/notes/770-taking-keuntungan -of-rspec-s-let-in-sebelum-blok

Penting untuk diingat bahwa membiarkan malas dievaluasi dan tidak memasukkan metode efek samping di dalamnya jika tidak Anda tidak akan dapat mengubah dari membiarkan ke sebelumnya (: masing-masing) dengan mudah. Anda bisa menggunakan let! alih-alih membiarkannya dievaluasi sebelum setiap skenario.

Secara umum, let()ini adalah sintaks yang lebih bagus, dan ini menghemat Anda mengetik @namesimbol di semua tempat. Tapi, emptor peringatan! Saya telah menemukan let()juga memperkenalkan bug halus (atau setidaknya menggaruk kepala) karena variabel tidak benar-benar ada sampai Anda mencoba menggunakannya ... Katakan tanda dongeng: jika menambahkan putssetelah let()untuk melihat bahwa variabel benar memungkinkan spec untuk lulus, tetapi tanpa putsspesifikasi gagal - Anda telah menemukan kehalusan ini.

Saya juga menemukan bahwa let()sepertinya tidak ada cache dalam semua keadaan! Saya menulisnya di blog saya: http://technicaldebt.com/?p=1242

Mungkin hanya saya?

biarkan fungsional karena pada dasarnya Proc. Juga di-cache.

Satu gotcha saya temukan langsung dengan let ... Dalam blok Spec yang mengevaluasi perubahan.

let(:object) {FactoryGirl.create :object}

expect {
  post :destroy, id: review.id
}.to change(Object, :count).by(-1)

Anda harus memastikan untuk menelepon di letluar blok harapan Anda. yaitu Anda menelepon FactoryGirl.createdi blok let Anda. Saya biasanya melakukan ini dengan memverifikasi objek tetap ada.

object.persisted?.should eq true

Kalau tidak, ketika letblok disebut pertama kali perubahan dalam database akan benar-benar terjadi karena kemalasan malas.

Memperbarui

Hanya menambahkan catatan. Berhati-hatilah bermain golf kode atau dalam hal ini golf rspec dengan jawaban ini.

Dalam hal ini, saya hanya perlu memanggil beberapa metode yang merespon objek. Jadi saya memanggil _.persisted?metode _ pada objek sebagai kebenarannya. Yang saya coba lakukan adalah instantiate objek. Anda bisa menelepon kosong? atau nihil? terlalu. Intinya bukan ujian tetapi membawa objek kehidupan dengan menyebutnya.

Jadi kamu tidak bisa refactor

object.persisted?.should eq true

menjadi

object.should be_persisted 

sebagai objek belum instantiated ... malas. :)

Perbarui 2

memanfaatkan let! sintaks untuk pembuatan objek instan, yang harus menghindari masalah ini sama sekali. Perhatikan bahwa itu akan mengalahkan banyak tujuan kemalasan dari let non banged.

Juga dalam beberapa kasus Anda mungkin benar-benar ingin memanfaatkan sintaks subjek alih-alih membiarkan karena dapat memberi Anda opsi tambahan.

subject(:object) {FactoryGirl.create :object}

Catatan untuk Joseph - jika Anda membuat objek database di a before(:all)mereka tidak akan ditangkap dalam transaksi dan Anda lebih cenderung meninggalkan cacat di database pengujian Anda. Gunakan before(:each)sebagai gantinya.

Alasan lain untuk menggunakan let dan evaluasi malasnya adalah agar Anda dapat mengambil objek yang rumit dan menguji masing-masing potongan dengan mengesampingkan let dalam konteks, seperti dalam contoh yang sangat dibuat-buat ini:

context "foo" do
  let(:params) do
     { :foo => foo,  :bar => "bar" }
  end
  let(:foo) { "foo" }
  it "is set to foo" do
    params[:foo].should eq("foo")
  end
  context "when foo is bar" do
    let(:foo) { "bar" }
    # NOTE we didn't have to redefine params entirely!
    it "is set to bar" do
      params[:foo].should eq("bar")
    end
  end
end

"sebelum" secara default menyiratkan before(:each) . Ref The Rspec Book, hak cipta 2010, halaman 228.

before(scope = :each, options={}, &block)

saya menggunakan before(:each) untuk seed beberapa data untuk setiap grup contoh tanpa harus memanggil letmetode untuk membuat data di blok "it". Lebih sedikit kode dalam blok "it" dalam kasus ini.

saya menggunakan let jika saya ingin beberapa data dalam beberapa contoh tetapi tidak pada yang lain.

Baik sebelum dan membiarkan sangat bagus untuk KERINGAN blok "itu".

Untuk menghindari kebingungan, "biarkan" tidak sama dengan before(:all). "Biarkan" mengevaluasi kembali metode dan nilainya untuk setiap contoh ("itu"), tetapi cache nilai di beberapa panggilan dalam contoh yang sama. Anda dapat membaca lebih lanjut di sini: https://www.relishapp.com/rspec/rspec-core/v/2-6/docs/helper-methods/let-and-let

Suara dissenting di sini: setelah 5 tahun rspec saya tidak terlalu suka let.

1. Evaluasi malas sering membuat pengaturan tes membingungkan

Menjadi sulit untuk berpikir tentang pengaturan ketika beberapa hal yang telah dinyatakan dalam pengaturan tidak benar-benar mempengaruhi keadaan, sementara yang lain.

Akhirnya, karena frustrasi seseorang hanya berubah letke let!(hal yang sama tanpa evaluasi malas) untuk mendapatkan kerja spesifikasi mereka. Jika ini berhasil bagi mereka, sebuah kebiasaan baru lahir: ketika spec baru ditambahkan ke suite yang lebih lama dan itu tidak berhasil, hal pertama yang penulis coba adalah menambahkan poni ke acaklet panggilan .

Segera semua manfaat kinerja hilang.

2. Sintaks khusus tidak biasa bagi pengguna non-rspec

Saya lebih suka mengajar Ruby kepada tim saya daripada trik rspec. Variabel instan atau panggilan metode berguna di mana-mana dalam proyek ini dan lainnya, letsintaks hanya akan berguna di rspec.

3. "Manfaat" memungkinkan kita untuk dengan mudah mengabaikan perubahan desain yang baik

let()bagus untuk dependensi mahal yang tidak ingin kita buat berulang kali. Ini juga berpasangan dengan baik subject, memungkinkan Anda untuk mengeringkan panggilan berulang ke metode multi-argumen

Ketergantungan yang mahal berulang kali, dan metode dengan tanda tangan besar adalah titik di mana kita bisa membuat kode lebih baik:

• mungkin saya bisa memperkenalkan abstraksi baru yang mengisolasi ketergantungan dari sisa kode saya (yang berarti lebih sedikit tes yang membutuhkannya)
• mungkin kode yang diuji terlalu banyak
• mungkin saya perlu menyuntikkan objek yang lebih cerdas daripada daftar panjang primitif
• mungkin saya memiliki pelanggaran Tell-Don't-Ask
• mungkin kode mahal dapat dibuat lebih cepat (lebih jarang - waspadalah terhadap pengoptimalan prematur di sini)

Dalam semua kasus ini, saya dapat mengatasi gejala tes sulit dengan balsem sihir rspec yang menenangkan, atau saya dapat mencoba mengatasi penyebabnya. Saya merasa seperti saya menghabiskan terlalu banyak dari beberapa tahun terakhir pada yang pertama dan sekarang saya ingin beberapa kode yang lebih baik.

Untuk menjawab pertanyaan awal: Saya lebih suka tidak melakukannya, tetapi saya masih menggunakan let. Saya sebagian besar menggunakannya untuk menyesuaikan dengan gaya tim lainnya (sepertinya kebanyakan programmer Rails di dunia sekarang jauh ke dalam sihir rspec mereka sehingga sangat sering). Kadang-kadang saya menggunakannya ketika saya menambahkan tes ke beberapa kode yang saya tidak punya kendali, atau tidak punya waktu untuk refactor ke abstraksi yang lebih baik: yaitu ketika satu-satunya pilihan adalah penghilang rasa sakit.

Saya gunakan letuntuk menguji tanggapan HTTP 404 saya di spesifikasi API saya menggunakan konteks.

Untuk membuat sumber daya, saya menggunakan let!. Tetapi untuk menyimpan pengenal sumber daya, saya menggunakan let. Lihatlah seperti apa tampilannya:

let!(:country)   { create(:country) }
let(:country_id) { country.id }
before           { get "api/countries/#{country_id}" }

it 'responds with HTTP 200' { should respond_with(200) }

context 'when the country does not exist' do
  let(:country_id) { -1 }
  it 'responds with HTTP 404' { should respond_with(404) }
end

Itu membuat spesifikasi tetap bersih dan mudah dibaca.