RSpec：説明、コンテキスト、機能、シナリオ？

describe、context、feature、scenario：4の間の差（S）とするとき、私は一つ一つを使用しないとは何ですか？

context別名であるdescribeので、彼らは機能的に同等です。それらを交換して使用できます。唯一の違いは、スペックファイルの読み取り方法です。たとえば、テスト出力に違いはありません。RSpec本は言う：

「私たちはdescribe()物事やcontext()文脈のために使う傾向があります」。

個人的には使用しdescribeたいのですが、人々が好む理由がわかりcontextます。

featureとscenarioカピバラの一部であり、RSpecではなく、受け入れテストに使用するためのものです。feature同等でdescribe/ context、およびscenarioに相当it/ example。

Capybaraで受け入れテストを作成している場合は、feature/ scenario構文を使用し、そうでない場合はdescribe/ it構文を使用します。

今朝、いくつかの仕様を書いている間に、私は同じ質問をしていました。通常、私は主に使用しdescribe、特にこれについては考えていませんが、今朝は1つのモジュールの多くのケースとさまざまな仕様を扱っていたため、それらの仕様を読む次の開発者が簡単に理解できるようにする必要がありました。それで私はこれについてグーグルに尋ねました、そして私はこれを見つけました：rspecでコンテキストとコンテキストを説明します、その答えは私が非常に興味深いと思います：

rspecのソースコードによると、「コンテキスト」は単に「説明」のエイリアスメソッドです。つまり、これら2つのメソッドに機能的な違いはありません。ただし、コンテキストの違いがあり、両方を使用してテストをより理解しやすくするのに役立ちます。

「説明」の目的は、1つの機能に対して一連のテストをラップすることであり、「コンテキスト」は、同じ状態の1つの機能に対して一連のテストをラップすることです。

したがって、この原則に基づいて、次のような仕様を作成します。

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do
  
  # 1st state of the feature/behaviour I'm testing
  context "without a order param" do
    ...
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with a given order column" do
    ..
  end

  # Last state of the feature/behaviour I'm testing
  context "with a given order column + reverse" do
    ..
  end
end

これが一般に受け入れられているルールかどうかはわかりませんが、このアプローチは明確で、簡単に理解できます。

ドキュメントによると、ピエールの優れた答えを拡張します：

機能とシナリオDSLは、それぞれ記述とそれに対応しています。これらのメソッドは単に機能の仕様を顧客および受け入れテストとして読み取ることができるエイリアスです。

したがって、Mochaの用語を説明し、それに慣れているユーザーは、テストの動作をユーザーの観点から説明するのに適しているため、Mochaは主にフロントエンドのテストフレームワークとして機能します。

• いつもとのみ使用することを選択describeし、itまたは別のペアリング
• 特定のアプリの状態で複数のアサーション/テストを行う必要itがあるcontextブロック内で使用することを選択します

2番目のオプションを使用すると、「同じ状態の1つの機能に対する一連のテストを...ラップ[ping]」するという意図に従うことができます。

したがって、テストは次のようになります。

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do

  # 1st state of the feature/behaviour I'm testing
  context "without an order param" do
    # 1st and only test we want to run in this state
    it "asks the user for missing order param" do
     ...
    end
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with an invalid order param" do
    # 1st test we want to run in this state
    it "validates and rejects order param" do
      ...
    end
    # 2nd test we want to run in this state
    it "returns an error to user" do
      ...
    end
  end

  # 3rd state of the feature/behaviour I'm testing with multiple tests
  context "with a valid order param" do
    it "validates and accepts order param" do
      ...
    end
    it "displays correct price for order" do
      ...
    end
    unless being_audited
      it "secretly charges higher price to user" do
        ...
      end
    end
  end
end

このように、あなたはスキップします featureは、特定のフロントエンド機能に使用したり、FDD（機能主導開発）を実行している場合に一部のユーザーにとって不快に感じる可能性があるキーワードを完全に。ここで開発者チームに入力を依頼してください。

警告：常に業界標準に準拠しているとは限りません。フォルクスワーゲンの哲学に従ってすべてのテストをモデル化したとしたらどうでしょうか。