JBehaveはJavaベースのアプリケーションに適したJavaベースの&です。 JBehaveは良いHTMLレポートもサポートしています。しかし、JBehaveの問題は、Storyレベルのみをサポートし、Featureレベルはサポートしないということです。キュウリを使ってフィーチャレベルで受け入れテストを書くにはどうすればいいですか？
キュウアンがフィーチャレベルをどのようにサポートしているのかわかることができる小さな説明やドキュメントをお寄せください。
機能は機能の実装です（機能には複数の機能が必要な場合があります）。
それはかなり良いなので、のは「物語」のMike Cohn's descriptionを見てみましょう：
ユーザーストーリーは、通常、新しい機能を希望する人の 視点から語ら機能の短い、簡単な説明です システムのユーザーまたは顧客。
As a <type of user>, I want <some goal> so that <some reason>.
優れたユーザーストーリーがINVEST principlesに追従し、我々はシナリオに取得を開始これはどこです：それが配信されることを意味し
ストーリーには、機能が動作する1つまたは複数のコンテキストが含まれている可能性がありますo仕事。コンテキストは、その性質上、他のコンテキストとは独立しています。
それを書き換えることができますので、あなたが考慮する必要がある他のコンテキストや成果を見つけることができます。機能の中核となる機能は、通常、「いつ」に関連付けられます。たとえば、私はレポートを生成できるようにしたい場合は「いつ」「私はレポートを生成すると...」、貴重な
結果が異なる複数の利害関係者がいるかもしれません。たとえば、運転手が予約されたというメールを送信することは重要ですが、運転手に予約確認を送信することも重要です。異なるステークホルダーを考慮して、考慮する必要のあるシナリオの結果を考え出します。あなたのサイズを見積もることができない場合
を推定することができるので、ちょうど作業1つのシナリオを取得してみてください。これはKent Beckの「スパイク」と機能的に同等です。ちなみに、見積もりが必要な唯一の理由は、実行できる他の作業があれば、実行する価値があるかどうかを判断することです。
私は実際に、彼らはそれについて不確実性のいくつかのレベルを持って知っている人を好む、そしてできるだけ早くフィードバックを得るために見えます。あなたが本当にそれについて確信しているなら（例：ログイン）、あなたはより少ないフィードバックを必要とするので、それがより大きくなることはOKです。あなたは "働く"ものがどのように見えるか知っています。関連する説明は、それに
例をテストするのに十分に含まなければならないことを意味テスト可能
私たちはなぜ最初に物語をしますか？なぜ全機能を提供するだけではないのですか？
いくつかの機能を出荷するために必要な作業は、特に多くのステークホルダーが関与している場合にはかなり大きくなります。以前に価値を得るためには、それらをスライスしたい、または私たちはそれらをスライスしてフィードバックを得ることができます。
ストーリーは、実際に出荷することができる機能のスライスか、フィードバックを得るためのものである可能性があります。
シナリオはこれを行う素晴らしい方法です。この機能は、最も価値のあるコンテキスト、または結果を考慮する必要のある異なるステークホルダーに絞り込むことができます。取引ニーズのある利害関係者（ATMのユーザーはお金を得る、銀行は口座を借りる）や規制上のニーズを排除しないように注意してください（銀行は大きな投資を行い、規制当局は資本準備金の変更を見ます）。
シナリオはではなく、フィーチャーのフィードバックを得る方法です。新しいUI？何の振る舞いもせずにハードコードし、人々にそれを示す。新しいレポート？擬似コピーを作成します。誰も処理していない新しいフィード？スパイクを作って、あなたができると思う情報を得ることができるかどうかを見てください。
それ以外の場合は、結果を考慮する必要のあるさまざまなコンテキストとステークホルダーを検討し、それぞれのコンテキストと成果によって異なる能力を検討してください。機能はさまざまな要件を実装しています。その動作は、得られたシナリオで説明されています。
話が機能を通してスライスされ、かつ機能が機能を実装しているので、これは典型的な階層である：
シナリオをストーリーや機能に関連付ける方法を試している場合、これは悪い方法ではありません。 Gojko Adzic's "Impact Mapping"またはMatt Wynne's "Example Mapping"（私たちは皆、Chris Mattsを聞いて得たと思う）を見れば、それはよく知られています。
実際にはこれは少しばかげているので注意してください。あなたが配信を開始するときに発見を行いますので、事前にすべてを壊さないでください。私は能力が良い計画レベルの成果物を作り出し、しばしば「Epics」とかなり簡単に関連付けられていることがわかります。彼らはまた、独自のハイレベルテストを提供しています。「ユーザーが必要とするものを、必要とする状況に対して、またその結果が必要なステークホルダーに提供できるか」
話だけで、それが実際に配信されるまでは、価値を提供するためにを必要なのかを検討することです...そして、残りの一部は必要なの次ものになるだろう、など
とトリック他のアイデアについては、私のブログはcapability-based planning and lightweight analysis、もう1つはsplitting up storiesです。
キュウリの場合は、能力別に整理し、必要に応じて文脈で整理し、チェックインにストーリーナンバーを付けてください（ほとんどのCIツール、電子ボード、バージョン管理システムがこれをサポートしています）。機能やストーリーがより多くのシナリオを作成することはOKです。
リズありがとう、私はこのような美しいブログを今までに見つけられておらず、私の質問に答える時間をとってくれてありがとう。かなり明確で思いやりのある説明。 –
JBehaveとキュウリは本当に違いはありません。彼らはシナリオのコレクションを参照するために異なる言葉を使用します。 JBehaveの言葉は私にとってはあまり正しいとは言えませんが、Cucumberと同じように使用することはできます。おそらく、この答えは誤解の原因です：http://stackoverflow.com/a/8304995/634576私はあまりにもコメントしました。 –