ruby-on-rails - 実際の例で BDD を理解する

Question

私はビヘイビア駆動開発アプローチに参加しようとしていますが、それを使用するには、そのように考える方法を理解する必要があります。

今始めている新しい個人プロジェクトでテストしたい (RoR を使用します)

このプロジェクトは、外部アプリケーションからデータを収集するための API を提供し、認証システム (デバイス)、必要に応じてデータを収集するためのいくつかのモデル、およびいくつかのプレミアムのみの機能を提供するサブスクリプションを購入するための支払いシステムを提供します。

DRY 以外のすべての機能をカバーするには、どのような種類のテストを実行する必要がありますか?

RSpec と Cucumber の両方を使用する必要があると考えました。Devise については、彼らの Web サイトのドキュメントに従いますが、データが正しく収集され、ユーザーに正しく表示され、そのタスクにどのツールが使用されているかを確認するために、どのような種類のテストを実行する必要があるかが明確ではありません。また、この種のプロジェクトのテストと開発をどのように整理するかの簡単な例を提供できれば、役に立ちます (実際のテスト コードについては質問していません。実際のテスト コードについては、実際には実装に依存していることがわかっているため)、開発プロセスと実行するテストの種類)。選択するためにさらに詳細が必要な場合は、教育目的であるため、私に知らせてください。

Answer 1

BDD については、コミュニケーションがすべてであるという点で、だれかが口を挟むことなく言及することはできないと思います。だから私はその男になります: コミュニケーションがすべてです! 真の価値は、システムが透過的に行う必要があることを確立するために、さまざまな利害関係者とのアクセス可能な用語で機能を調査することです。全員が同じ言語を話すことで、目標を簡単に伝えることができます。実装に関しては、開発者は自分が何をしているかを知っており、利害関係者は自分たちが何を得ているかを知っており、あまり多くの驚きがあってはなりません (見逃した/間違ってキャプチャした/まだ気付いていないことを除いて)。

ですから、そこに出て、利害関係者と話し、システムを委託する人が何をしたいのかを考え出してください。これが単独の作業である場合は、さまざまな帽子をかぶる必要があります。

BDD テストは、システムの動作 (必要な機能の単位) をカバーします。単体テストなどは引き続き行う必要があります。変更はありません。

プロダクト オーナーとして、システムに何をしてもらいたいかを考えてください。方法ではありません。機能している限り、物事がどのように機能するかは気にしないでしょう。あなたが開発者であれば、これはおそらく難しい考え方の変化です。最初に BDD を検討し始めたとき、シナリオで UI の旅や技術的な詳細などを確認することは理にかなっていると確信していました。そうではありません。そのようなものはステップ定義に属します。開発者として、そこにすべての方法を定義できます。

DRY を維持することについては…必要な動作をキャプチャするために、必要な方法でシナリオを正確に記述します。その後、リファクタリングと、ステップの再利用の機会の特定について心配することができます。ここでも、正規表現の使用がある程度役立ちます。非常に命令的になり、再利用可能な一連のステップ全体を用意するのは魅力的ですが、単一のステップへの変更が想定されたシナリオだけでなく、すべてのシナリオに波及すると、すべてが非常に脆弱であることに気付くでしょう。影響。あらゆる形式の Web 自動化に興味がある場合は、Web 自動化ピラミッドを確認してください。

有用なリソース (および多くの例):

http://books.openlibra.com/pdf/cuke4ninja-2011-03-16.pdf < すばらしい無料の電子ブック – 読むのも楽しい。

http://www.slideshare.net/lunivore/behavior-driven-development-11754474 < リズは本当に自分のことを知っています!

http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/

https://www.google.co.uk/search?q=declarative+vs+imperative+BDD < go Team Declarative!

Answer 2

これがあなたの正確な要件を満たしているかどうかはわかりませんが、これが私がBDDを行う方法です(例はwebappです):

アプリケーションのユーザーとして、コンピューターの前に座っているとします。ユースケースの 1 つを達成するために実行する必要がある手順を書き留めます。たとえば、次のようになります。

システムの URL に移動します ログイン 必要な機能を選択します 機能を実行するための関連データを入力します ボタンをクリックして機能を開始します システムが応答するのを待ちます 画面上のデータが期待するデータと一致することを確認します。

これらのステップのいずれかの実行に失敗した場合、またはデータが正しくない場合、テストは失敗しています。

これをテスト ファイルに記述したら、Gherkin/Cucumber/Webdriver を使用して、各ステップの実行に必要なコードを実装します。この各メソッドは再利用可能であるため、ログインを 1 か所に実装すると、それを呼び出したすべての場所で機能するはずです。

Answer 3

キュウリまたはrspecを使用してテストする場合は、これを試してください

これを参照してください-cucumber/rspec またはgithub