そのため、RSpecストーリーの使用を開始したいのですが、書き込みコントローラー、モデル、およびビューの仕様がどこに適合するのかわかりません。
たとえば、「ユーザーが間違ったパスワードを提供する」というシナリオで「ログイン」するという話がありますが、コントローラー/モデルの仕様（response.should render ...、user.should be_nilなど）と同じものをテストすることになりませんか？ 。）
だから私の質問は：RoRでbdd（またはstory dd）を行うことに慣れている人のために、あなたはまだモデル/コントローラーの仕様を書いていますか？もしそうなら、あなたが従うワークフローはどうですか（「最初の話、次に特定の仕様に絞り込む」）？
（レガシーストーリーがたくさんあるのではなく）今ストーリーから始めている場合は、RSpecストーリーランナーの長期的な代替品であるCucumberを検討することをお勧めします。
仕様とストーリーを分割する最も簡単な方法は、ストーリーを使用してビジネス要件のフルスタックテストを行い、仕様をコンポーネント（ビュー、ヘルパー、コントローラー、モデル）の分離された低レベルの仕様に使用することです。「フルスタック」は、コントローラー/モデル/データベースからWebratを使用したクライアントシミュレーション、WatirまたはSeleniumを使用したブラウザー内テストまで多岐にわたります。
物事を行うための究極の「外部」のBDD方法は、顧客の要件に基づいたストーリーから始めて、ストーリーを実装するときに必要と思われるコンポーネントの仕様を追加することです。理想的には、個々のコンポーネントを仕様で完全にカバーし、ユーザーの最も重要なワークフローのストーリーを用意して、アプリが要求された機能を提供していることを最高レベルで確認できるようにします。
ストーリーは、ユーザーが実際に実行または観察する動作をテストするときに役立つと思います。したがって、「失敗したログイン」テンプレートがレンダリングされることをテストするのではなく、応答に「失敗したログイン」が含まれていることをテストします。モデルインスタンスを手動で作成せずにステップを機能させるのは難しい場合もありますが、ストーリーがモデル、ビュー、またはコントローラーを直接参照しない方がよいと思います。
私が見ているように、ビュー、コントローラー、モデルの仕様は全体像の一部にすぎません。彼らは実装の言語を話し（「コントローラーアクションXはモデルZに対してYを実行する必要があります」）、アプリの個々の部分がそれぞれ正しいことを実行することをテストします。ストーリーは、ユーザーの言語を話し（「コメントを投稿すると、投稿したコメントが表示されるはずです」）、顧客の受け入れ基準を満たす方法でパーツが組み合わされていることをテストすることで、全体像を完成させます。
便利なワークフローは次のとおりです。
そうすれば、ストーリーはあなたのスペックがテストする必要があるものをあなたに導くことができます。
編集：これはストーリーとスペックの関係に触れる良い記事です。
Pat Maddox (RSpec コア チーム) は、いくつかの仮定の下では、Cucumber のストーリー/機能を使用するときにコントローラーの仕様をスキップできると考えています。
彼の見解についてはこちら
Cucumber+Capybara がある場合、ビュー スペックをスキップするのはどうでしょうか。ビュースペックは必要ないと思う傾向があります。