Rspecの機能仕様とリクエスト仕様の概念的な違いは何ですか？
機能仕様ドキュメントから：
機能仕様は、アプリケーションを通じて機能のスライスを実行することを目的とした高レベルのテストです。彼らは通常、外部インターフェイス（通常はWebページ）を介してのみアプリケーションを駆動する必要があります。
そしてリクエスト仕様について：
要求仕様は、Railsの統合テストの薄いラッパーを提供し、ルーティング（Railsによって提供される）やスタブなし（ユーザー次第）など、フルスタック全体で動作を駆動するように設計されています。リクエスト仕様を使用すると、次のことができます。
- 単一のリクエストを指定する
- 複数のコントローラーにまたがる複数のリクエストを指定する
- 複数のセッションにわたって複数のリクエストを指定する
機能仕様はカピバラを使用し、要求仕様は使用しないことを知っています。しかし、それは異なる概念にほとんどメリットがありません。
回答:
概念的な違いは、通常はユーザーストーリーをテストすることであり、すべての操作はユーザーインターフェースを介して行う必要があります。そこで登場するのがCapybaraです。リクエストスペックはまだアプリケーションの動作をテストしており、受け入れテストのような読みやすさの期待はありません。したがって、受け入れテストの構文を改善するための機能があります。
技術的な違いには、要求仕様がRails統合テストをラップするのに対して、機能仕様はそうではありません。つまり、リクエストスペックでは、メソッドget、post、put、delete、および反アサートを使用できます。機能仕様では、ブラウザを介したすべての対話を促進し、訪問やページに対するアサートなどのメソッドを使用する必要があります。
githubのrspec-railsソースコードにあるfeature_spec.featureを読むことをお勧めします。これがお役に立てば幸いです。
"GET /login"で期待にブロックをitのようなブロックexpect(response.status).to eq(200)やexpect(response).to render_template(:new)、またはでdescribe "POST /sessions"、context "with valid credentials"で、ブロックをexpect(response).to redirect_to(user)してfollow_redirect!; expect(response.body).to include("Signed in")
visit users_path）またはハードコードされた文字列（visit '/users'）を使用することをお勧めしますか？個人的には、そのような仕様ではアプリの内部を使用しないことを好みます。