22

私は初めてBDD（Behavior Driven Design）を使用しようとしており、問題へのこの異なるアプローチ方法に慣れようとしています。

BDDを使用した単純なログインアプリケーションなどのために作成するストーリー/シナリオをいくつか挙げていただけますか？

たとえば、私が読んだことから、それは良いようです：

ユーザーが無効なユーザーID/パスワードを入力すると、エラーメッセージが表示されます。

とは対照的に：

データベースで一致するレコードを検索して、IDとパスワードを検証します。

4

3 に答える 3

13

Dan North は、ストーリーを書く上で優れたアドバイスを提供しています。「ダン・ノース - ストーリーの内容は?」

また、理解可能で実行可能な方法でこれらのストーリーを書く方法を考えるのに多くの時間を費やしているため、 Cucumberに関して行われている作業のいくつかも見ていきます。

于 2009-05-31T17:51:14.917 に答える
7

_Kevin が言及した Dan North の記事は素晴らしいです。

ただし、実際に作成するか、少なくともクライアント/ユーザーから収集する必要がある「ユーザー ストーリー」があることを忘れないでください。これらは、「私が欲しいので、そのように」タイプの物語です。

次に、ユーザー ストーリーがいつ、どのように満たされていると見なされるかを特定する受け入れ基準があります。それはあなたが投稿に書いたようなものです:「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));
}

テスト構文は気にしないでください。仕様テキスト自体がテスト クラス名とメソッド名に組み込まれていることがわかります。さらに、テスト/仕様は実際にクラスの動作をテストしています。このような単純なユーザー ストーリーのテストに合格すると、受け入れ基準が満たされたことになります。

于 2009-06-01T06:43:20.020 に答える
0

ここで素晴らしい講演を見つけましたhttps://skillsmatter.com/skillscasts/2446-bdd-as-its-meant-to-be-done (注意、ビデオを表示するにはアカウントを作成する必要があります)

于 2015-11-22T01:16:22.353 に答える