121

Java用の各BehaviorDrivenDevelopment（BDD）フレームワークの長所と短所は何ですか？

たとえば、ここでそれらのいくつかを見つけました。

すでにモックライブラリ（ Mockitoなど）を使用している場合、BDDフレームワークを使用するのは理にかなっていますか？

4

8 に答える 8

99

Java 用の 3 つの BDD フレームワークの比較が完了しました。明らかに、私の調査結果は使用期限がかなり短いです。

コンコーディオン

  • 非常に柔軟
  • 非常にきれいなレポート出力
  • 素敵なプラグイン フレームワーク
  • 不十分に文書化されています。私はそれを理解するためにソースを読まなければなりませんでした (幸いなことに、その非常に優れた品質です)。
  • フィクスチャは、html に密結合される可能性が高いように思われました。

イージービー

  • 非常に浅い学習曲線 (非 Groovy 開発者であっても)
  • 非常に強力な DBUnit 統合
  • どうやらパラメータのサポートはありません (非常にあいまいなストーリーまたはテキストとコードの重複につながります (編集: 実際にはありますが、そのドキュメントは非常にうまく隠されていました)。
  • ストーリーとコードは非常に密接に結合されています (同じファイル)
  • 非常に基本的なレポート出力
  • IntelliJ プラグインを動作させることができませんでした
  • 非アクティブなコミュニティ (Maven プラグインは 3 か月間壊れていたようです - 利用できるコード例は多くありません)

JBehave

  • 非常に強力で柔軟 (例: 前提条件としてストーリーを構成することで定型文を削減)
  • 広範な (断片化されている場合) ドキュメントと例
  • さまざまなフレームワークと環境に対する広範な (圧倒的ではあるが) サポート
  • ストーリー ファイルとコードの優れた分離
  • かなり活発なコミュニティがあり、ウェブ上でより多くの例と議論があるようです.
  • かなり急な学習曲線 (Concordion/EasyB よりも理解するのに 3 ～ 4 倍の時間がかかりました)

私は、JDave の Cuke4Duke を試す機会がありませんでしたが、現時点ではおそらく JBehave を推し進めるでしょう。

于 2011-05-01T23:43:44.597 に答える
36

「長所と短所」は人によって異なる場合があります。普段はちょくちょく見てます

  • 開発活動。たとえば、新しいリリースの可能性が高いか、2 年前の最後のリリースです。
  • 成熟度、たとえば、それがどのくらいの期間使用されているか、チュートリアルや書籍が利用可能かどうかなどです。（私はこれらの本を読んでいません。それは単なる養子縁組のしるしです。）
  • ツールのサポート、たとえば Eclipse プラグイン、Ant サポートなどはありますか
  • 依存関係のサイズ、独自のすべてが付属するフレームワークは好きではありません。たとえば、モッキング フレームワークを自分で選択したい。
  • 一種のライセンス、これは私が働いている会社の法的条件のため、私にとって重要です.
  • 関連するツールとの互換性。たとえば、Gherkin 言語を使用しているかどうか。

そして、私が見たいくつかのフレームワークから

  • 本能 悪い: 2010 年 3 月の最後の活動、良い: ASF ライセンス
  • JDave 悪い: マッチャーとモックが付属、良い: 2011 年 1 月の最後のアクティビティ、ASF ライセンス
  • easyb 悪い: 最後の活動は 2010 年 10 月、不明: Groovy を使用しています。これは問題ないかもしれませんが、私の場合、採用には問題があります。
  • beanspec が悪い: 2007 年にバージョンが 1 つしかなく、これは死んでいる
  • bdoc が悪い: 最後の活動は 2010 年 1 月です。よくわかりません: コードからレポートを作成して、逆の方向に進んでいるようです。
  • spock 悪い: 少し極端かもしれませんが、これは完全なテスト フレームワークであり、BDD だけではありません。良い: 非常にアクティブで、非常にクールです。
  • jbehave、Java のすべての BDD の「母」、悪い: 非常に強力 = 複雑、互換性のないライセンス (私にとって)、ほぼすべてのテスト ライブラリなどに付属、良い: RSpec に基づいているため、互換性がある、Eclipse プラグイン、Maven 統合、非常に活発なコミュニティ
  • ginkgo4jは Java 用の BDD フレームワークであり、これも Ruby の RSpec に基づいていますが、(注釈の代わりに) Java ラムダを使用して、高度にコンテキストに依存した読みやすいテストを作成できるようにします。単純。とてもパワフルな。オープン ソース Apache 2 ライセンス。

モックについて: モック フレームワークも必ず必要です。BDD フレームワークは単に仕様を記述するのに役立ちますが、一部のテストではモックやスタブが必要になります。トップダウンで設計する場合 (概要から詳細まで)。

于 2012-01-19T21:55:08.987 に答える
20

Java で使用するのに最適な BDD フレームワークは何ですか? なんで？各フレームワークの長所と短所は何ですか?

Concordion vs. Cucumber および Java ベースの受け入れテストに関する興味深いリンクを次に示します。

ここでそれらのいくつかを見つけましたが、どれを選択すればよいかわかりません。

実際、上記のものを見てください。

すでにモッキング ライブラリ (Mockito など) を使用している場合、BDD フレームワークを使用する意味はありますか?

Short answer: yes, definitely. Actually, acceptance testing using a BDD framework and unit testing in isolation using mock objects are so different that I don't really get the question. Acceptance testing is black box testing, tests are used to verify that a business feature is working and are ideally written by business analyst. Unit tests in isolation using mocks is white box testing, tests are used to verify that a unit is working and are written by developers. Both are useful buty they have totally different purposes. In other words, using Mockito doesn't replace a BDD framework at all and the inverse is also true.

于 2010-02-10T07:37:17.187 に答える
7

私はもともとプレーンなjUnitでBDDを実行していましたが、jUnitで実行していたこととほぼ1：1であるため、最近JDaveを調べています。また、jUnit上で実行されるため、すでにEclipseで動作し、Hudsonなどの継続的インテグレーションシステムで動作するように簡単に構成できます。他の人と実際に比較することはできませんが、JDaveでの私の経験はこれまでのところ良好です。

ああ、モックを使うのは決して愚かな考えではありません！それらは特にTDD/BDDに結び付けられておらず、それらの目的は一般的なテストの負担を軽減することです。

于 2009-07-01T22:45:02.543 に答える
6

うわー、話題が熱いですね、良い答えがたくさんあります...

皮肉なことはさておき、私は最近 BDD を発見し、その概念が興味深いと感じました。ねえ、それはテストと仕様の両方を書くことを強制します! 驚くかもしれませんが、プロジェクトによっては後者が欠落している可能性があります...または、BDD が強制的に導入する精度が不足しているだけです。

Behavior Driven Developmentの記事には、概念がまとめられており、いくつかの優れた記事 (Andrew Glover によって書かれたものなど) へのリンクがまとめられています。さらに、このスレッドのトピックでは、かなり包括的な (私が推測する) BDD フレームワークのリストが提供されており、そのかなりの数が Java 用です。
フレームワークを選択する問題は解決しませんが、少なくとも検索が容易になります...

BDD はテスト コードの可読性に大きく依存しているため、クイック ツアー/チュートリアルを見て、どちらが自分のスタイルに適しているかを判断することを選択するのが適切な基準だと思います。その他の基準としては、フレームワークが使い慣れたツール (単体テスト、モック) を活用していること、IDE での使用法などがあります。

于 2010-01-06T10:13:29.247 に答える
4

Cucumber-JVM (以前は Cuke4Duke として開発されていました) を試しました。仕様に Gherkin DSL を使用し、プレーン テキストとして保存します。

Eclipse 4.2 での Cucumber-JVM の例

JUnit テストとして実行できます。したがって、それを使い始める唯一の問題は、ビジネス担当者または製品マネージャーがソース内の .features を読み書きできるようにすることです。

結果

于 2012-12-17T10:17:25.270 に答える
3

私のチームはJBehaveを使用して成功しました。EasyBを使用した後、JBehaveに移行し、プレーンテキストのシナリオファイルの処理が簡単であることがわかりました。

于 2011-03-02T15:58:02.067 に答える
3

私のチームはしばらくの間JBehaveを使用しています。プレーン テキスト ファイルを使用して仕様を保存します。すべてのステップ (Given、When、Then) は、ステップからパラメーターを抽出できる特定のメソッドによって実行されます。シナリオはインデントされ、適切にフォーマットされているため、クライアントがシナリオを検証したい場合に非常に役立ちます.

いくつかの問題もあります。Java 6 に切り替えました。実行中に一部のシナリオ ステップが無視されることがあります。バグがどこにあるのかを突き止めるのに多くの問題が発生する可能性があります。

于 2010-02-10T07:17:58.507 に答える