BDD は「アウトサイド イン」の方法論であり、私が理解しているように、知っていることから始めることを意味します。ストーリーとシナリオを作成し、最も外側のドメイン オブジェクトを実装し、サービス レイヤー、ドメイン レイヤーなどを下って、「内側に」移動し、「意図的に」コラボレーターを発見します。まだ存在していないコラボレーターの場合は、あなたはそれを作るまでそれを嘲笑する（または「偽造する」）. (これらの用語のいくつかは、Dan North と Kent Beck から直接盗用しています)。
では、UI はこれにどのように適合するのでしょうか?
North のブログ エントリの 1 つから借りて、彼は次のように書き直しました。
Given an unauthenticated user
When the user tries to navigate to the welcome page
Then they should be redirected to the login page
When the user enters a valid name in the Name field
And the user enters the corresponding password in the Password field
And the user presses the Login button
Then they should be directed to the welcome page
これに：
Given an unauthenticated user
When the user tries to access a restricted asset
Then they should be directed to a login page
When the user submits valid credentials
Then they should be redirected back to the restricted content
彼はこれを、UI ( 「名前フィールド」、「パスワード フィールド」、「ログイン ボタン」 ) など、関連のないドメインから言語を排除するために行います。これで、UI が変更されても、ストーリー (というか、ストーリーの意図) が壊れることはありません。
では、このストーリーの実装を書くとき、UI を使うべきでしょうか? ブラウザーを起動して、Selenium テストを介して「ユーザーが有効な資格情報を送信する」を実行するか、基盤となる実装 (認証サービスなど) に直接接続する方がよいでしょうか? ところで、私はBDD フレームワークとしてjBehaveを使用していますが、Cucumber、rSpec、またはその他の多くのものを簡単に使用できます。
私は自動化された方法で UI をテストしない傾向があり、Selenium のような GUI 自動化ツールには慎重です。なぜなら、テストは (1) 過度に脆く、(2) 実行コストが最大になる場所で実行されると思うからです。そのため、UI の美学と使いやすさを手動でテストし、ビジネス ロジックを下位の、より自動化が容易なレイヤーに任せることが私の傾向です。(そして、レイヤーが変更される可能性が低い可能性があります。)
しかし、私はこれについて回心することにオープンです。では、BDD は UI のためのものでしょうか。
PS。私はこのトピックで見つけることができる SO に関するすべての投稿を読みましたが、実際に私の質問に対処するものはありません。 これは最も近いものですが、UI を別の話に分けることについて話しているわけではありません。むしろ、BDD の目的で完全に無視することについて話しているのです。