Rails アプリケーションと Cucumber (以前の rspec-stories) の仕様はいつ使用する必要がありますか? もちろん、スペックの仕組みと積極的な使用方法の両方を知っています。しかし、Cucumber を使用するのはまだ奇妙に感じます。これに関する私の現在の見解は、クライアント用のアプリケーションを実装していて、システム全体がどのように機能するのかまだ理解していない場合、Cucumber を使用すると便利だということです。
しかし、自分のプロジェクトを行っている場合はどうなりますか? ほとんどの場合、システムの各部分がどのように相互作用するかを知っています。私がする必要があるのは、一連の単体テストを作成することだけです。キュウリが必要な場合、どのような状況が考えられますか?
そして、対応する 2 番目の質問として、Cucumber のストーリーを書く場合、仕様を書かなければなりませんか? 同じことの二重検査ではないでしょうか？
まだお読みでない場合は、Dan North の優れた記事What's in a Story?をご覧になることをお勧めします。出発点として。
Cucumber ストーリーには主に 2 つの用途があります。まず、ストーリー形式が非常に具体的であるため、製品所有者が構築したい機能の明確化に集中するのに役立ちます。これは、ストーリーの「会話のトークン」の使用であり、コードでストーリーを実装するかどうかにかかわらず、価値があります。第二に、プロセスが十分に機能しており、機能の作成を開始する前に完全なストーリーを作成できる場合 (日々の現実というよりも、私たちが目指している理想に近いものです)、受け入れ基準が明確に綴られており、何をどのように行うかを正確に把握できます。構築することがたくさん。
Rails の作業では、Cucumber のストーリーは rspec 単体テストの代わりにはなりません。二人は手を取り合って行きます。実際には、単体テストはモデルとコントローラーの開発を促進する傾向があり、ストーリーはビューの開発を促進する傾向があり (ビューの rspec を作成しない傾向があります)、アプリケーション全体の優れたテストを提供します。ユーザーの視点。
一人で作業している場合、コミュニケーションの側面はそれほど興味がないかもしれませんが、Cucumber から得られる統合テストは興味深いかもしれません。webratを利用すれば、Cucumber の作成は、多くの基本機能に対して高速かつ簡単に行うことができます。
それをサイクルと考えてください：
Cucumber の機能を書き、その機能の部品を開発しながら仕様を書き、個々のコンポーネントを完成させます。機能が合格するのに十分な機能を記述するまで、仕様の完成を続けてから、次の機能を記述します。
私の見解では、Cucumber の構文がもたらす生産性のコストのために、ほとんどの状況で Cucumber を使用するのは悪い考えです。このトピックについては、なぜキュウリのテストに悩まされるのかというトピックについて詳しく書きました。
Cucumber のストーリーは、コードの個々の部分 (つまり、単体テスト) が機能するかどうかというよりも、アプリケーションが解決しようとしている問題全体の説明です。
Abie が説明しているように、これはアプリケーションが満たすべき要件のリストに近いものであり、クライアントとのコミュニケーションに非常に役立ち、直接テストすることもできます。
最近では、Capybara と Selenium Webdriver で rspec を使用できるので、Cucumber のストーリー パーサーをすべて構築して維持する必要がなくなります。これが私がお勧めするものです：
ただし、注意すべきことは、コントローラーと統合テストには不要な重複がある可能性があるため、時間を無駄にしないように最善の判断を下す必要があるということです。
また、自分の溝を見つけたら、BDD を使用して開発するのが最も楽しいことに気付くでしょう。君ならできるさ！
しかし、自分のプロジェクトを行っている場合はどうなりますか? ほとんどの場合、システムの各部分がどのように相互作用するかを知っています。私がする必要があるのは、一連の単体テストを作成することだけです。キュウリが必要な場合、どのような状況が考えられますか?
キュウリはまだ必要です。システムがどのように機能しているかを文書化するために必要であり、何かを変更したときに機能が壊れていないことを確認するためにも必要です。
つまり、単体テストが必要なのと同じ理由で、Cucumber ストーリーが必要です。より高いレベルの抽象化で機能するだけです。