5

BDDに関する小さな記事を書いた後、BDD（特にNBehave）を大規模に使用するケースがあるかどうかという質問がありました。

だから私の質問はコミュニティに行きます：あなたはBDDをうまく使ったプロジェクトがありますか？もしそうなら、あなたはどのような利益を得ましたか、そして何がもっと良かったでしょうか？もう一度BDDをしますか？他の人にもお勧めしますか？

4

4 に答える 4

4

さまざまなシナリオ (オープン ソース プロジェクトと ND プロジェクト) でコード レベルで BDD を使用しました。

  1. MVC シナリオでビューに伝える、ユーザーから受け入れる入力の種類 ( DDD および .NET でのルール駆動型 UI 検証)

    result = view.GetData(
  CustomerIs.Valid, 
  CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));

  2. 例外処理の動作について、サービス レイヤーに伝えます ( ActionPolicyはデコレーターに挿入されます)。

    var policy = ActionPolicy
  .Handle<WebException>()
  .Retry(3);

これらのアプローチを使用すると、コードの重複が大幅に減少し、コードベースがより安定して柔軟になりました。さらに、複雑な詳細が論理的にカプセル化されているため、すべてがよりシンプルになりました。

于 2009-02-05T09:31:06.773 に答える
3

私は、Web サイトで BDD を使用する小さなチームに所属していました。

使用方法は基本的に TDD でしたが、テストは DSL を使用して動作として単純に記述されています。ビヘイビアの大規模な事前設計には踏み込みませんでしたが、多数のビヘイビアを作成し、テストとまったく同じように使用しました。

ご想像のとおり、TDD とほぼ同じように機能し、一般的には良好でした。テストを行動として表現することは、顧客とやり取りするときに素晴らしく、かなりまともなドキュメントを作成しましたが、動作が英語で書かれ、テストがプログラミングされていないことを望む難しい中間言語を考え出そうとするのではなく、どちらの目的にも完全に適合します。

simple.spaces ではなく、random_looks.set of_Punctuation で区切られた言語に言語をひねろうとするこのかわいいトリックがなければ、それでも BDD になりますが、それは私の不機嫌そうな古いプログラマーの態度にす​​ぎませんでした。それと。

サイトは利用可能で、完全に機能しているので、成功と言えます。

于 2009-01-30T23:22:28.223 に答える
1

私は最近、高レベルの要件ドキュメントで GWT の BDD スタイルを使用しました。顧客から GWT についてのフィードバックはありませんでした。私の上司は、GWT が非常に明確で理解しやすいので気に入ったと言っていました。彼は私が知っている BDD の知識を持っていないことに注意してください。伝統的な滝の背景を持つ人々にとって、これはおそらく少し風通しの良い妖精だったので、私はユーザーストーリーを入れませんでした. 次回はユーザーストーリーを入れてみようかな。

ちなみにこれは目玉UIプロジェクトではありません。これは、Web サービスからデータベースにデータを同期する統合プロジェクトでした。つまり、GWT が「眼球」以外の UI でも機能することを示しています。

于 2009-02-27T07:30:37.340 に答える
0

私はいくつかのプロジェクトで（MSpecを使用して）コンテキスト仕様スタイルを使用しており、大きな成功を収めています。私はまだシナリオスタイルの本当の利点を理解しようとしています。コンテキスト指定スタイルを使用すればするほど、それが好きになり、アプリケーションがよりタイトに感じられます。

于 2009-08-23T05:00:22.853 に答える