RSpec let（）を使用する場合

beforeブロックを使用してインスタンス変数を設定する傾向があります。次に、これらの変数を私の例全体で使用します。最近出会いましたlet()。RSpecのドキュメントによると、それは

...メモ化されたヘルパーメソッドを定義します。値は、同じ例の複数の呼び出しにわたってキャッシュされますが、例全体ではキャッシュされません。

これは、beforeブロックでインスタンス変数を使用する場合とどう違うのですか？また、いつlet()vs を使用する必要がありますbefore()か？

私は常にletいくつかの理由でインスタンス変数を好む：

• インスタンス変数は、参照されると存在するようになります。つまり、インスタンス変数のスペルを太った場合、新しい変数が作成されてに初期化されnil、微妙なバグや誤検知につながる可能性があります。letメソッドを作成するので、NameErrorスペルを間違えるとを取得します。スペックのリファクタリングも簡単になります。
• before(:each)フックは例がフックで定義されたインスタンス変数のいずれかを使用しない場合でも、それぞれの例の前に実行されます。これは通常大したことではありませんが、インスタンス変数の設定に長い時間がかかる場合は、サイクルを浪費しています。によって定義されたメソッドのlet場合、初期化コードは、例がそれを呼び出した場合にのみ実行されます。
• 例の参照構文を変更せずに、例のローカル変数からletに直接リファクタリングできます。インスタンス変数にリファクタリングする場合、例でオブジェクトを参照する方法を変更する必要があります（例：を追加@）。
• これは少し主観的ですが、Mike Lewisが指摘したように、仕様を読みやすくしていると思います。私は、すべての依存オブジェクトを定義してlet、itブロックを簡潔かつ簡潔に保つ構成が好きです。

関連リンクはここにあります：http : //www.betterspecs.org/#let

インスタンス変数を使用したとの違いlet()それでlet()あるレイジーに評価。これは、let()それが定義するメソッドが初めて実行されるまで評価されないことを意味します。

との違いはbefore、変数のグループを「カスケード」スタイルで定義する優れた方法letをlet()提供することです。これを行うことにより、コードを簡略化することで、スペックが少し良くなります。

rspecテストでインスタンス変数のすべての使用法を完全に置き換えて、let（）を使用しました。小さなRspecクラスを教えるためにそれを使用した友人のための簡単な例を書きました：http ://ruby-lambda.blogspot.com/2011/02/agile-rspec-with-let.html

ここでの他の回答のいくつかが言うように、let（）は遅延評価されるため、ロードが必要なものだけをロードします。仕様を乾燥させ、読みやすくします。実際、Rspec let（）コードをコントローラーで使用できるように、inherited_resource gemのスタイルで移植しました。http://ruby-lambda.blogspot.com/2010/06/stealing-let-from-rspec.html

遅延評価に加えて、もう1つの利点は、ActiveSupport :: Concern、およびload-everything-in spec / support /動作と組み合わせて、アプリケーションに固有の独自の仕様mini-DSLを作成できることです。RackおよびRESTfulのリソースに対してテストするためのものを作成しました。

私が使用する戦略は、ファクトリーエブリシング（Machinist + Forgery / Faker経由）です。ただし、before（：each）ブロックと組み合わせて使用​​して、サンプルグループのセット全体のファクトリをプリロードし、仕様をより高速に実行することができます：http : //makandra.com/notes/770-taking-advantage -of-rspec-s-let-in-before-blocks

letは遅延評価され、副作用メソッドを入れないことを覚えておくことが重要です。そうしないと、letからbefore（：each）に簡単に変更できなくなります。レット使用できます！letの代わりに、各シナリオの前に評価されます。

一般に、let()はより優れた構文であり、@name記号を入力する手間が省けます。しかし、注意を払う必要があります！私を発見したlet()追加場合：あなたはそれを使用しようとするまで、変数が実際に存在していないので...物語記号を伝えるにも微妙なバグ（あるいは少なくとも頭掻く）を導入putsした後、let()変数が正しいことを確認するためにはスペックを可能に合格しputsますが、仕様がなければ失敗します-この微妙な点を見つけました。

またlet()、すべての状況でキャッシュされないようです。私はブログにそれを書きました：http : //technicaldebt.com/?p=1242

多分それは私だけですか？

letは本質的にProcとして機能します。また、そのキャッシュ。

letですぐに見つけた1つの問題...変更を評価しているSpecブロックで。

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

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

あなたはletあなたのexpectブロックの外で呼び出すことを確認する必要があります。つまりFactoryGirl.create、letブロックで呼び出しています。私は通常、オブジェクトが永続化されていることを確認することでこれを行います。

object.persisted?.should eq true

そうしないと、letブロックが初めて呼び出されたときに、遅延インスタンス化のためにデータベースの変更が実際に発生します。

更新

メモを追加するだけです。この回答では、コードゴルフ、またはこの場合はrspecゴルフのプレーに注意してください。

この場合、オブジェクトが応答するメソッドを呼び出すだけです。したがって_.persisted?、オブジェクトの_メソッドをその真実として呼び出します。私がやろうとしているのは、オブジェクトをインスタンス化することだけです。あなたは空と呼ぶことができますか？またはnil？あまりにも。ポイントはテストではありませんが、それを呼び出すことによってオブジェクトに生命をもたらします。

だからあなたはリファクタリングできません

object.persisted?.should eq true

することが

object.should be_persisted 

オブジェクトがインスタンス化されていないので...その遅延。:)

アップデート2

レッツを活用！この問題を完全に回避する必要がある、インスタントオブジェクト作成の構文。ただし、非バンレットレットの遅延の目的の多くは無効になります。

また、一部のインスタンスでは、追加のオプションが提供される場合があるため、letではなく実際に対象の構文を活用したい場合があります。

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

ジョセフへの注意-データベースオブジェクトを作成している場合、before(:all)それらはトランザクションでキャプチャされず、テストデータベースに残骸を残す可能性が高くなります。before(:each)代わりに使用してください。

letとその遅延評価を使用するもう1つの理由は、この非常に不自然な例のように、コンテキストでletをオーバーライドすることにより、複雑なオブジェクトを取得して個々の部分をテストできるようにするためです。

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

デフォルトの「前」はを意味しますbefore(:each)。Ref The Rspec Book、copyright 2010、page 228。

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

「it」ブロックにデータを作成するメソッドをbefore(:each)呼び出さなくても、サンプルグループごとにデータをシードするために使用しletます。この場合、「it」ブロック内のコードは少なくなります。

letいくつかの例で一部のデータが必要な場合に使用します。

beforeとletはどちらも「it」ブロックを乾燥させるのに最適です。

混乱を避けるために、「let」はと同じではありませんbefore(:all)。「Let」は、各例（「it」）のメソッドと値を再評価しますが、同じ例の複数の呼び出しにわたって値をキャッシュします。詳しくは、https：//www.relishapp.com/rspec/rspec-core/v/2-6/docs/helper-methods/let-and-letをご覧ください。

ここで反対意見：5年のrspecの後、私はあまり好きではありませんlet。

1.遅延評価はテストのセットアップを混乱させることが多い

セットアップで宣言されているものの一部が実際には状態に影響を与えていない場合、セットアップに理由を付けるのは難しくなります。

結局、欲求不満から、誰かが仕様を機能させるために（遅延評価なしで同じこと）に変更letしlet!ます。これがうまくいくと、新しい習慣が生まれます：新しい仕様が古いスイートに追加されて機能しない場合、作者が最初に試みるのはランダムなlet呼び出しに前髪を追加することです。

間もなく、パフォーマンス上のメリットはすべてなくなります。

2.特別な構文は、rspecを使用していないユーザーには珍しい

私は、rspecのトリックよりも、Rubyをチームに教えたいと思っています。インスタンス変数またはメソッド呼び出しは、このプロジェクトおよび他のあらゆる場所で役立ちletます。構文は、rspecでのみ役立ちます。

3.「メリット」により、優れた設計変更を簡単に無視できます

let()何度も作成したくない高価な依存関係に適しています。またsubject、と適切にペアリングされ、複数の引数を持つメソッドへの繰り返しの呼び出しをドライアップできます。

高価な依存関係が何度も繰り返され、署名が大きいメソッドは、どちらもコードを改善できるポイントです。

• おそらく、依存関係を残りのコードから分離する新しい抽象化を導入できます（つまり、必要なテストの数が少ないということです）
• テスト中のコードが多すぎる
• プリミティブの長いリストではなく、よりスマートなオブジェクトを注入する必要があるかもしれません
• 多分私は教えないでくださいの違反があります
• おそらく、高価なコードをより速くすることができます（まれに-ここで時期尚早な最適化に注意してください）

これらすべてのケースで、rspecマジックの鎮静剤を使用して困難なテストの症状に対処するか、原因に対処することができます。過去数年間を前者に費やしすぎたような気がしますが、今はもっと良いコードが欲しいです。

元の質問に答えるには、私はしたくないのですが、それでも使用しますlet。私はほとんどの場合、チームの他のメンバーのスタイルに合わせるために使用します（世界中のほとんどのRailsプログラマーは今やrspecのマジックに深く関わっているようです）。制御できないコードにテストを追加するときや、より適切な抽象化にリファクタリングする時間がないとき、つまり、唯一のオプションが鎮痛剤であるとき、それを使用することがあります。

letコンテキストを使用して、API仕様でHTTP 404応答をテストするために使用します。

リソースを作成するには、を使用しますlet!。しかし、リソース識別子を保存するには、を使用しますlet。それがどのように見えるか見てみましょう：

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

これにより、仕様がクリーンで読みやすくなります。