私はそれを理解しようとしているBDDの初心者です..BDDについての私の理解は..でした。
「これは、ユーザーの仕様を使用してビジネスからUbquitious言語を生成する一種のテストです」
しかし、例ではUIの例しか見ることができません。ボタンが押されたときのように..ユーザーがテキストを入力したとき...これは私のコードで使用できる言語を形成しません。
この概念を理解するのは間違っていますか
私はそれを理解しようとしているBDDの初心者です..BDDについての私の理解は..でした。
「これは、ユーザーの仕様を使用してビジネスからUbquitious言語を生成する一種のテストです」
しかし、例ではUIの例しか見ることができません。ボタンが押されたときのように..ユーザーがテキストを入力したとき...これは私のコードで使用できる言語を形成しません。
この概念を理解するのは間違っていますか
BDD(Behavior Driven Design)は、Dan Northによって造られた用語であり、彼の意図を理解するための最良の情報源は、この優れたブログ投稿です。
ここでは、Danがテストの詳細から代わりに動作を説明することに焦点を移したいと考えていることを読むことができます。もちろん、これは非常に多くの方法で解釈できます(そして確かに解釈されています:)。ですから、どこに目を向けても、意見が分かれるでしょう。これが私のものです。
SpecFlowのようなCucumberベースのツールのアイデアは、関係者全員が読んで理解できる言語とツールで、機能についてのチームの共有理解を書き留めることです。これは、この機能の使用方法に関するいくつかのシナリオまたは例を書き留めることによって(これもCucumberベースのツールで)行われます。この仕様を例として呼ぶ人もいます。
このように例を使用して仕様を作成することで、ある程度のメリットが得られます。
さて、最後にあなたの質問に移りましょう(ちなみに、これは私が自分自身や他の人によく尋ねる素晴らしい質問です)。言い換えればすみません、私はあなたの意図を理解することを願っています:
私のシナリオはUIに対して実行する必要がありますか(または実行する必要がありますか)?
UIに対してシナリオを実行する必要はありません。BDDの原則とツールは、どのレイヤーのドメインに対してもうまく機能します。
ただし、仕様を最大限に活用するには、上記の私の(決定的ではない)リストを検討する必要があります。GUI(またはデータベース、サービスなど)を含めないと、アプリケーションスタック全体が正しく連携して機能するかどうかを確認できません。そのため、仕様はエンドツーエンドで実行されることがよくあります。
そして、これにより、これらの「テスト」は単体テストとは非常に異なるものになります(これは、稲妻のように高速にし、外部の依存関係をモックアウトし、データベースにアクセスしないなど)。それらは実行に時間がかかります。すべてのチェックインで実行するべきではありません。モックを使用しないでください。
多くの場合、シナリオのステップから始めて、動作のドライバーとして、通常のTDDを使用してシステムの内部の詳細を追い出します。これはアウトサイドインプログラミングです。
最後に、上記の例に移ります。したがって、データベースに至るまで、UIに対してエンドツーエンドで仕様を実行することをお勧めします。ただし、UIを上記のように技術用語で説明することをお勧めします(ボタン、リンク、テキストボックスなどを使用)。BDD Googleグループでこの質問をしたとき、ElisabethKeoghから素晴らしいヒントを得ました。
UIを説明しないでください。代わりに、UIで何を達成しようとしているのかを説明してください。
したがって、ログイン機能を説明するために、次のように記述しないでください。
Scenario: Login (describing the UI)
Given I am on the Login-page
When I enter 'AUser' in the textbox 'UserName'
And I enter 'APassword' in the textbox 'Password'
And I click the 'Login' button
Then I should see the following text 'You are logged in'
むしろ次のように書いてください。
Scenario: Login (describing what we want to achieve)
Given I am not logged in
When I log in using 'AUser' and 'APassword'
Then I should be logged in
そのため、コードで記述したステップ定義でこれを行う方法(ボタンをクリックする、フォームに入力する、メッセージを確認するなど)が複雑になります。
これがお役に立てば幸いです。また、私は他のより経験豊富なBDDの人々から来る可能性のあるいくつかの「バッシング」に備えています。しかしねえ、これは私の2セントです:)
私はまだBDDとSpecflowにかなり慣れていません。これを使用して、動作を確立し、コントローラーをコード化して、ビューを駆動します。目の前にコード例はありませんが、後で投稿するものを見つけようとします。乾杯!
編集-ところで、キュウリの使用に関する優れた本を探している場合(Specflowと同じ言語を使用しています-Gherkin?私はまだすべての部分をまっすぐにしています)、 PragmaticProgrammersのRSpecBookを強くお勧めします。コードはRubyベースですが、プロジェクトの定義と実行に関するより高いレベルの章がいくつかあります。価格に見合う価値があります。