RSpec vs Cucumber（RSpecストーリー）[終了]

Railsアプリケーションの仕様を使用する必要があるのはいつですか？もちろん、仕様がどのように機能し、積極的に使用されているかはわかっています。しかし、それでもキュウリを使用するのは変だと感じています。これに関する私の現在の見解は、クライアントにアプリケーションを実装しているときにCucumberを使用すると便利であり、システム全体がまだどのように機能するかを理解していないということです。

しかし、私が自分のプロジェクトをしている場合はどうなりますか？ほとんどの場合、システムの各部分がどのように相互作用するかを知っています。私がしなければならないのは、たくさんの単体テストを書くことだけです。私がキュウリを必要とする可能性のある状況は何ですか？

そして、対応する2番目の質問として、キュウリのストーリーを作成する場合、仕様を作成する必要がありますか？同じことの二重テストではないでしょうか？

まだ読んでいない場合は、Dan Northの優れた記事「What's in a Story？」をチェックしてみてください。出発点として。

キュウリのストーリーには2つの主な用途があります。まず、ストーリー形式は非常に具体的であるため、製品所有者が構築したい機能を明確に説明するのに役立ちます。これはストーリーの「会話のためのトークン」の使用法であり、コードにストーリーを実装したかどうかに関係なく価値があります。次に、プロセスが十分に機能して、機能の作成を開始する前に完全なストーリーが得られる場合（日常の現実よりも、私たちが努力する理想の方が理想的です）、受け入れ基準が明確に記述されており、何をどのようにしているかを正確に把握しています構築する多く。

Railsの作業では、Cucumberストーリーはrspecユニットテストの代わりにはなりません。二人は手をつないで行く。実際には、単体テストはモデルとコントローラーの開発を推進する傾向があり、ストーリーはビューの開発を推進する傾向があり（ビューのrspecを記述しない傾向があります）、アプリケーション全体の優れたテストを提供します。ユーザーの視点。

一人で作業している場合、コミュニケーションの側面はそれほど興味深いものではないかもしれませんが、Cucumberから取得する統合テストは興味深いかもしれません。webratを利用する場合、Cucumberを書くことは多くの基本的な機能にとって速くて苦痛のないことです。

それをサイクルと考えてください：

Cucumber機能を記述し、その機能の部品を開発しながら、仕様を記述して個々のコンポーネントを完成させます。機能が合格するのに十分な機能を作成するまで仕様を完成させ、次の機能を作成します。

私の見解では、構文があなたに負担する生産性のコストのために、ほとんどの状況でCucumberを使用することは悪い考えです。私はなぜキュウリの検査でわざわざするのかというトピックについて広範囲に書きましたか？

Cucumberストーリーは、個々のコードが機能するかどうか（ユニットテストなど）ではなく、アプリケーションが解決する全体的な問題の説明です。

Abieが説明しているように、これはアプリケーションが満たす必要のある要件のリストのほとんどであり、クライアントとの通信に非常に役立ち、直接テストすることもできます。

今日では、rspecをCapybaraおよびSelenium Webdriverで使用して、すべてのCucumberストーリーパーサーを構築および保守する必要をなくすことができます。これが私がお勧めするものです：

1. ストーリーを書きなさい
2. RSpecを使用して、統合テストを作成します。例：spec / integrations / socks_rspec.rb
3. 次に、新しいシナリオを含む統合テストを作成し、シナリオごとにブロックします
4. 次に、統合テストを取得するために必要な最小限の機能を実装し、さらに深く（コントローラーやモデルなどに）進みながら、コントローラーやモデルでTDDを実行します。
5. 戻ると、統合テストに合格し、統合テストにステップを追加し続けることができます
6. 繰り返す

ただし、注意すべき点の1つは、コントローラーテストと統合テストが重複している可能性があるため、時間を無駄にしないように最善の判断をする必要があることです。

また、グルーブを見つけたら、BDDを使用して開発するのが最も楽しいと感じるでしょう。それまでは、完璧にやっているとは思わず、考えすぎないようにして、罪悪感を感じないでください。君ならできるさ！

しかし、私が自分のプロジェクトをしている場合はどうなりますか？ほとんどの場合、システムの各部分がどのように相互作用するかを知っています。私がしなければならないのは、たくさんの単体テストを書くことだけです。私がキュウリを必要とする可能性のある状況は何ですか？

まだキュウリが必要です。システムがどのように機能しているかを文書化するために必要であり、変更したときに機能が損なわれていないことを確認するためにも必要です。

言い換えれば、単体テストが必要なのと同じ理由でキュウリストーリーが必要です。それらはより高いレベルの抽象化で機能するだけです。