私はBDD（Behavior Driven Design）を初めて使用しようとしており、このようなさまざまな問題に慣れようとしています。BDD（Behavior Driven Design）でストーリー/シナリオを書く方法
BDDを使用した簡単なログインアプリケーションのような記事やシナリオを書くことはできますか？
例えば、私が読んだものから、それは良いようです：
ユーザが無効なユーザーID /パスワードを入力
は、エラー メッセージを表示します。 データベース内の一致するレコードを検索することにより検証IDおよびパスワードとは対照的に
。
Dan Northはストーリーを書く上で優れたアドバイスを持っています。 "Dan North- What's in a Story?"
また、理解できる実行可能な方法でこれらのストーリーを書く方法について多くの時間を費やしてきたので、Cucumberの作業の一部を見ていきます。
ケビンが言及したダンノースの記事は素晴らしいです。
実際に書かれているか、少なくともクライアント/ユーザーから収集されているはずの「ユーザーストーリー」があることに注意してください。これらは、「もっと、私がしたい、そういうもの」のようなものです。
次に、ユーザのストーリーがどのようにいつ満足されると言われるかを識別する承認基準があります。それは、あなたがあなたの投稿に書いたようなものです：「xのときはyです。」
プロジェクト管理システムでは「システムストーリー」と呼ばれ、テストではユーザーが気づいていないかもしれないが、クラス間のやり取りを記述する「仕様」が重複しています。 システムストーリー：「LoginHandlerにログインとパスワードが与えられると、LoginValidatorでデータを検証する必要があります。 仕様：
[TestFixture]
public class When_the_login_handler_is_given_a_login_and_password
{
constant string login = "jdoe";
constant string password = "password";
static LoginValidator loginValidator;
context c =() => loginValidator = an<ILoginValidator>;
because b =() => sut.Validate(login, password);
it should_validate_the_data_with_a_LoginValidator =
() => loginValidator.was_told_to(x => x.DoValidation(login, password));
}
ネヴァーマインドテスト構文は、あなたは、仕様テキスト自体がテストクラス名やメソッド名に具現化されていることがわかります。さらに、テスト/スペックは実際にクラスの動作をテストしています。このようなテストが単純なユーザーストーリーに合格すると、合格基準が満たされます。
私は
（注意は、あなたがビデオを表示するには、アカウントを作成する必要があります）ここに素晴らしい話 https://skillsmatter.com/skillscasts/2446-bdd-as-its-meant-to-be-done を見つけました