JavaのBDDフレームワークの違いは何ですか？[閉まっている]

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

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

すでにモッキングライブラリ（例：Mockito）を使用している場合、BDDフレームワークを使用しても意味がありますか？

Java用の3つのBDDフレームワークの比較を終えたところです。明らかに、私の調査結果の使用期限はかなり短いです。

コンコーディオン

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

EasyB

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

JBehave

• 非常に強力で柔軟性がある（例：前提条件としてのストーリーの構成によるボイラープレートの削減）
• 広範な（断片化されている場合）ドキュメントと例
• さまざまなフレームワークと環境に対する広範な（圧倒的な場合）サポート
• コードからのストーリーファイルの優れた分離
• かなり活発なコミュニティがあり、ウェブ上でさらに多くの例とそれについての議論があるようです。
• かなり急な学習曲線（Concordion / EasyBの3〜4倍長い時間で理解できた）

思っていたように、JDaveのCuke4Dukeを試す機会はありませんでしたが、現時点ではおそらくJBehaveを使用するでしょう。

「長所と短所」は人によって異なる場合があります。私はいつも見ています

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

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

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

モックについて：モックフレームワークも間違いなく必要です。BDDフレームワークは仕様の作成を支援するだけですが、一部のテストではモックまたはスタブが必要になります。トップダウンで設計するとき（概要から詳細まで）。

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

これは、ConcordionとCucumberおよびJavaベースの受け入れテストに関する興味深いリンクです。

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

本当に、上記のものを見てください。

モッキングライブラリ（Mockitoなど）を既に使用している場合、BDDフレームワークを使用しても意味がありますか？

短い答え：はい、間違いなく。実際、BDDフレームワークを使用した受け入れテストとモックオブジェクトを使用した単体テストは非常に異なるため、実際には質問に答えません。受け入れテストはブラックボックステストです。テストは、ビジネス機能が機能していることを確認するために使用され、理想的にはビジネスアナリストによって記述されます。モックを使用した単体テストはホワイトボックステストです。テストは、ユニットが動作していることを確認するために使用され、開発者によって記述されます。どちらも便利ですが、目的はまったく異なります。つまり、Mockitoを使用してもBDDフレームワークがまったく置き換えられず、その逆も当てはまります。

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

ああ、モックを使用するのは決して愚かなことではありません！それらはTDD / BDDに特に関係していません、それらの目的は一般にテストの負担を軽減することです。

うわー、トピックがホットで、良い答えがたくさんあるようです...

皮肉なことに、私は最近BDDを発見し、その概念を興味深いものにした。ねえ、それはテストと仕様の両方を書くことを強いる！意外に思われるかもしれませんが、後者は一部のプロジェクトでも欠落している可能性があります...または、BDDが強制的に導入する精度に欠けています。

ビヘイビア駆動開発の記事（Andrew Glover著で書かれたような）いくつかの良い記事へのコンセプトとリンクをまとめています。さらに、このスレッドのトピックには、BDDフレームワークのかなり包括的な（おそらく）リストが表示されます。それらの多くはJava用です。
フレームワークを選択する問題は解決しませんが、少なくとも検索が容易になります...

BDDはテストコードの可読性に大きく依存しているので、クイックツアー/チュートリアルを見て、どちらのスタイルがあなたのスタイルによりふさわしいと思われるかを確認するのが良い選択基準だと思います。その他の基準としては、フレームワークが、使い慣れたツール（単体テスト、モック）、IDEでの使用などを活用していることがあります。

私が試したキュウリ-JVM（以前Cuke4Dukeとして開発を）。仕様にはGherkin DSLを使用し、プレーンテキストとして保存されます。

JUnitテストとして実行できます。したがって、それを使い始める唯一の問題は、ビジネスパーソンまたはプロダクトマネージャーにソースの.featuresを読み書きさせることです。

結果

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

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

私のチームはJBehaveを使用して成功しました。EasyBを使用した後、JBehaveに移行し、プレーンテキストのシナリオファイルの方が扱いやすいことがわかりました。