web-dev-qa-db-ja.com

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

describe、context、feature、scenario：4つの違いは何ですか。それぞれをいつ使用しますか？

rspecrspec2rspec-rails
98
mikeglaz

contextはdescribeのエイリアスであるため、機能的に同等です。これらは同じ意味で使用できますが、唯一の違いはspecファイルの読み取り方法です。たとえば、テスト出力に違いはありません。 RSpecの本にはこう書かれています：

「物事にはdescribe()を、コンテキストにはcontext()を使用する傾向があります」.

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

featureとscenarioはRSpecではなくCapybaraの一部であり、受け入れテストに使用することを意図しています。 featureはdescribe/contextと同等であり、scenarioはit/exampleと同等です。

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

131
Sam Peacey

今朝、いくつかの仕様を書いている間、私は同じ質問をしていた。通常、私は主にdescribeを使用し、特にこれについては考えませんが、今朝は多くのケースと1つのモジュールの異なる仕様を扱っていたため、次の開発者が簡単に理解できる必要がありましたそれらの仕様を読んでください。だから私はこれについてGoogleに尋ねました、そして私はこれを見つけました： 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

これが一般に受け入れられているルールであるかどうかはわかりませんが、このアプローチは明確で把握しやすいと思います。

30
Pierre-Adrien Buisson

Pierreの excellent answer を展開し、 docsによる に従って：

機能とシナリオDSLはそれぞれ、describeとitに対応します。これらのメソッドは、エイリアスであり、機能仕様が顧客テストおよび受け入れテストとしてさらに読み込めるようにします。

したがって、Mochaの用語「describe and it」（ユーザーの観点からテストの動作を記述するのに適しているため、Mochaは主にフロントエンドのテストフレームワークとして機能します）では、次のことができます。

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

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

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

#
# 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（機能駆動開発）を実行している場合に使用します。ここでの入力については、開発者チームにお問い合わせください。

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

0
GrayedFox