Java用のBDDフレームワークの違いは何ですか？
それぞれの長所と短所は何ですか Behavior Driven Development （BDD）Javaのフレームワーク？
それらのいくつかを見つけました ここ 、例えば。
モックライブラリを既に使用している場合、BDDフレームワークを使用するのは理にかなっていますか（例 Mockito ）？
Java用の3つのBDDフレームワークを比較しました。明らかに、私の調査結果の使用期限はかなり短いです。
- とても柔軟
- 非常にきれいなレポート出力
- 素敵なプラグインフレームワーク
- 不十分な文書化。私はそれを理解するためにソースを読まなければなりませんでした（幸運なことに、非常に良い品質です）。
- フィクスチャはhtmlと密接に結びついているように思われました。
- 非常に浅い学習曲線（Groovy以外の開発者でも）
- 非常に強力なDBUnit統合
- どうやらパラメーターのサポートがないようです（非常に曖昧なストーリーや、テキストとコードの重複につながります（編集：実際にはありますが、そのドキュメントは非常によく隠されていました）。
- ストーリーとコードは非常に密に結合されています（同じファイル）
- 非常に基本的なレポート出力
- IntelliJプラグインを機能させることができませんでした
- 非アクティブなコミュニティ（Mavenプラグインは3か月間壊れているようです-多くのコード例はありません）
- 非常に強力で柔軟（たとえば、前提条件としてのストーリーの構成によるボイラープレートの削減）
- 広範な（断片化されている場合）ドキュメントと例
- さまざまなフレームワークと環境の広範な（圧倒的であれば）サポート
- ストーリーファイルとコードの優れた分離
- かなり活発なコミュニティと、Web上でのより多くの例と議論があるようです。
- かなり急な学習曲線（Concordion/EasyBの3〜4倍の時間がかかりました）
Cuke4Duke of JDaveを試してみる機会はありませんでしたが、現時点ではJBehaveをプッシュするでしょう。
「賛否両論」は、人によって異なる場合があります。私は通常見て
- 開発活動、例えば新しいリリースであるか、2年前の最後のリリースです。
- 成熟度、例：それがどのくらいの期間でしたか、チュートリアルや多分本が利用可能です。 （私はこれらの本を読みません。それはただの採用のサインです。）
- ツールサポート、例： Eclipseプラグイン、Antサポートなどがありますか
- 依存関係のサイズ、私は独自のものがすべて付属するフレームワークが好きではありません。例えばモックフレームワークを自分で選択したいと思います。
- ライセンスの種類、これは私が働いている会社の法的条件のために私にとって重要です。
- 関連ツールとの互換性、例： Gherkin言語を使用するかどうか。
そして、いくつかのフレームワークから私は見ていた
- Instinctbad：最後のアクティビティ2010年3月、good：ASFライセンス
- JDavebad：マッチャーとモックが付属、good：最終アクティビティ2011年1月、ASFライセンス
- easybbad：最終アクティビティ2010年10月、わからない：Groovyを使用します。これは大丈夫かもしれませんが、私の場合は採用に問題があります。
- beanspecbad：2007年に1つのバージョンのみ、これは死んでいます
- bdocbad：最後のアクティビティ2010年1月、わからない：コードからレポートを作成する逆のように見えます。
- spockbad：少し極端かもしれませんが、これは完全なテストフレームワークであり、BDDだけでなく、 good：非常にアクティブで、非常にクールです。
- jbehave、JavaのすべてのBDDの「母」、bad：非常に強力な=複雑、互換性のないライセンス（私にとって）、ほぼすべてのテストライブラリなどに付属していますgood：RSpecに基づいているため、互換性がある、Eclipseプラグイン、maven統合、非常にアクティブなコミュニティ
- ginkgo4j、JavaのBDDフレームワークで、RubyのRSpecに基づいていますが、Javaラムダを使用しています（代わりに注釈）を使用すると、非常にコンテキストの高い読みやすいテストを作成できます。シンプル。とてもパワフルな。オープンソースのApache 2ライセンス。
モックについて：モックフレームワークも間違いなく必要です。 BDDフレームワークは仕様の作成に役立ちますが、一部のテストではモックまたはスタブが必要になります。トップダウンで設計するとき（概要から詳細まで）。
Javaで使用するのに最適なBDDフレームワークは何ですか？どうして？各フレームワークの長所と短所は何ですか？
Concordion vs. Cucumber and Java based Acceptance Testing に関する興味深いリンクがあります
私はここでそれらのカップルを見つけましたが、どれを選ぶべきか分かりません。
本当に、上記のものを見てください。
既にモックライブラリ（Mockitoなど）を使用している場合、BDDフレームワークを使用する意味がありますか？
簡単な答え：はい、間違いなく。実際、BDDフレームワークを使用した受け入れテストと、モックオブジェクトを使用した単体テストは非常に異なるため、実際には質問がありません。受け入れテストはブラックボックステストです。テストは、ビジネス機能が機能していることを確認するために使用され、理想的にはビジネスアナリストによって作成されます。モックを使用した単体での単体テストはホワイトボックステストです。テストは、ユニットが機能していることを確認するために使用され、開発者によって作成されます。どちらも便利ですが、まったく異なる目的を持っています。つまり、Mockitoを使用してもBDDフレームワークはまったく置き換えられず、その逆も当てはまります。
私はもともとプレーンなjUnitでBDDを実行しましたが、最近jUnitで行っていたこととほぼ1：1であるため、 JDave を見てきました。また、jUnitの上で実行されるため、すでにEclipseで動作し、Hudsonなどの継続的統合システムで動作するように構成するのも簡単です。他の人と実際に比較することはできませんが、JDaveでの私の経験は今のところ良好です。
ああ、モックを使用することは決して愚かな考えではありません！それらは特にTDD/BDDに結び付けられているのではなく、それらの目的は一般的なテストの負担を軽減することです。
うわー、トピックは暑くて、たくさんの良い答えがあります...
皮肉なことに、私は最近BDDを発見し、この概念が興味深いことに気付きました。ねえ、それはテストと仕様の両方を書くことを強制します！意外に思えるかもしれませんが、一部のプロジェクトでは後者が欠落している可能性があります...または、BDDが強制的に導入する精度が不足しています。
Behavior Driven Development の記事は、コンセプトといくつかの優れた記事（Andrew Gloverによって書かれたものなど）へのリンクをまとめたものです。さらに、このスレッドのトピックについては、かなり包括的な（おそらく）BDDフレームワークのリストを提供しますが、その多くはJava用です。
フレームワークを選択する問題は解決しませんが、少なくとも検索は容易になります...
BDDはテストコードの可読性に大きく依存しているため、選択の良い基準は、クイックツアー/チュートリアルを見て、どちらが自分のスタイルに合っているかを確認することだと思います。他の基準としては、フレームワークが使い慣れたツールを活用するという事実（単体テスト、モック）、IDEでの使用などがあります。
Cucumber-JVM （以前はCuke4Dukeとして開発されていました）を試しました。仕様にはGherkin DSLを使用し、プレーンテキストとして保存します。
JUnitテストとして実行できます。そのため、使用を開始するための唯一の問題は、ビジネスマンまたはプロダクトマネージャーがソースの.featuresを読み書きできるようにすることです。
結果
私のチームはJBehaveを成功裏に使用しました。EasyBを使用してからJBehaveに移行し、プレーンテキストシナリオファイルの方が扱いやすいことがわかりました。
私のチームはしばらくの間 JBehave を使用しています。プレーンテキストファイルを使用して仕様を保存します。すべてのステップ（Given、When、Then）は、ステップからパラメーターを抽出できる特定のメソッドによって実行されます。シナリオはインデントされ、適切にフォーマットされているため、クライアントがそれらを検証したい場合に役立ちます。
いくつかの問題もあります。 Java 6.に切り替えました。実行中にいくつかのシナリオのステップが無視される場合があります。バグの原因を突き止めるのに多くのトラブルを引き起こす可能性があります。