web-dev-qa-db-ja.com

BDDテストは受け入れテストですか？

Fitnesseテストがある場合、BDDのようなものが必要ですか？

bddfitnesseacceptance-testing
45
pondermatic

BDDの「テスト」は、最初のプロジェクトビジョンに至るまで、複数の異なるレベルの粒度で存在します。ほとんどの人はシナリオについて知っています。何人かの人々は、 BDDは「すべき」という言葉で始まった JUnitの「テスト」の代わりとして-TDDの代わりとして覚えています。私が「テスト」を引用符で囲んでいる理由は、BDDが実際にはテストに関するものではないためです。それは理解の欠如またはミスマッチがある場所を見つけることに焦点を合わせています。

その焦点のために、会話はBDDツールよりもはるかに重要です。

もう一度言います。 会話はBDDツールよりもはるかに重要です。

受け入れテストは実際には会話を義務付けるものではなく、通常、作成しているテストが正しいテストであるという前提から機能します。 BDDでは、自分が何をしているのかわからないと想定しています（そして、おそらくわからないこともわかりません）。これが、「Given、When、Then」などを使用する理由です。これにより、シナリオやユニットレベルの例について会話することができます。 （これらは、ほとんどの人が精通している2つのレベル（受け入れテストと単体テストに相当）ですが、規模は大きくなります）。

ビジネスパーソンに「受け入れテストを手伝ってください」と尋ねることができないため、「受け入れテスト」とは呼びません。彼らは本当に奇妙で細い視線であなたを見て、それからあなたをそのオタクの女の子として解雇します。あなたの93％はそれを望んでいません。

代わりに、「シナリオについてお話ししたいのですが...」をお試しください。または、「例を挙げていただけますか？」これらのどちらかが良いです。それらを「受け入れテスト」と呼ぶと、実際にテストを行っていると人々に思わせるようになります。これは、自分が何をしているかを知っていて、それを確実に実行したいということを意味します。その時点で、会話は、あなたが間違ったものを出しているという事実についてではなく、あなたが間違ったものをどれだけ早く出すことができるかに焦点を合わせる傾向があります。

そして、あなたは間違ったことをしている。 本当に、正直なところ、あなたはそうです。 あなたがそうではないと思っていても、それはあなたが二次無知を理解していないからです。couldあなたが知らないことを知っている場所を見つければ、あなたはあなたが知らないことを知りません、そしてそれは大丈夫です。 （すべてを見つけることはできません。分類のパラドックスがあなたを夜更かしさせないでください。）

それを本当に正しくする唯一の方法は、allの要件を前もって取得することであり、それを試してみるとどうなるかがわかります。そのとおり。Waterfallです。残業を覚えていますか？週末の仕事？あなたが作ったものが1つも生産に至らなかった7年？それを避けたいのであれば、チャンスは1つだけです。自分が間違っていると想定し、それについていくつかの会話をして、間違いが少なくなるようにしてから、自分がstillであることを受け入れます。間違って、とにかくそれのために行きます。テストの作成が早すぎるということは、moreが間違っている可能性さえあることを意味します。今では変更が難しくなり、誰もがあなたが正しいと思ってPMはあなたの速度を測定していて、今あなたはさらに2週間間違っていることにコミットしています。そして-さらに悪いことに-あなたもあなたが間違っていることをテストしようとしています。

もう一度。 会話はBDDツールよりもはるかに重要です。

ツールに固執しないでください。ツールは、会話をキャプチャし、それらがコードで再生されることを確認するための単なるメカニズムです。シナリオは会話の代わりにはなりません。3x5のインデックスカード以上が要件の代わりになります。

そうは言っても、mustツールから始める場合は、Fitnesseの後ろにSlimを置いて、Fitのテーブルや備品をいじることなく素敵なGiven/When/Thensを実行できるようにします。 。 GivWenZen はSlimに基づいており、どちらかがロックされています。 FitSharpは、.NETスペースにいる皆さんと同等です。または、Cucumber、SpecFlow、または 少しカスタムDSL *をノックアップ* を使用するだけで、何年も問題なく動作します。

透明性：*私はそれを書きました。そして、JBehaveのビット。それを「Dont-concentrate-on-BDD-tools-Behave」と呼んでいればよかったのにと思います。私はBDDの他の部分に深く関わっているかもしれません。さらに、私がこのメッセージを出すことができれば、ダン・ノースは私にパイントを買うでしょう、それでそれは正確に公平なアドバイスではありません。

とにかく-すでに会話をしている。それはただの人です。話してください。

118
Lunivore

厳密に言えば、「BDDテスト」のようなものがあるかどうかはわかりません。 BDDは、複雑なプロジェクトを完了するために、利害関係者と最もよく対話し、協力する方法を提案する哲学です。テストを書くための最良の方法を直接処方することはありません。言い換えれば、BDD哲学プロジェクトでは、通常の種類のテスト（受け入れテストを含む）がすべて残っている可能性があります。

「BDDフレームワーク」と聞くと、スピーカーは通常、通常の種類のテストをすべて作成するためのフレームワークを意味しますが、BDDのひねりが加えられています。たとえば、RSpecでは、単体テストを作成します。それらにBDDフレーバーを追加するだけです。

5
John Feminella

BDDは単なるテストの範囲よりも大きいですが、確かにBDDテストがあります。これらのテストは、BDD言語に従う単体テストです。

いくつかの初期コンテキスト（与えられた）が与えられた場合、イベントが発生したときに、いくつかの結果を確認します。

好みの言語に応じて、利用可能な優れたBDDフレームワークがいくつかあります。 JBehave for Java RSpec for Ruby NBehave for .NET

2
David Yancey

JBehave（およびNBehaveは最近同じサポートを追加しました）は通常のテストファイルで動作するため、他の多くのフレームワークは「BDDテイストtounitテスト」を追加しますが、JBehaveで作成されたテキストベースの動作仕様/例は受け入れテストに適しています。いいえ、そのためのフィットネスは必要ありません。

それがどのように機能するかを理解するために、私は提案します JBehaves 2minチュートリアル 。

2
Cellfish

「スペック」と「テスト」を区別するのが好きです。

GetAverage(IEnumerable<int> numbers)というメソッドをカバーしている場合は、多かれ少なかれ標準的な単体テストを作成します。

CalculateSalesTax(decimal amount, State state, Municipality municipality)というメソッドをカバーしている場合でも、単体テストを記述しますが、（1）の動作を検証するために変更するため、仕様と呼びます。ルーチン、および（2）テスト自体がルーチンとその受け入れ基準の両方を文書化するため。

考えてみましょう：

[TestFixture]
public class When_told_to_calculate_sales_tax_for_a_given_state_and_municipality() // the name defines the context
{
    // set up mocks and expected behaviour
    StateSalesTaxWebService stateService 
        = the_dependency<IStateSalesTaxWebService>;
    MunicipalSurchargesWebService municipalService 
        = the_dependency<IMunicipalSurchargesWebService>;

   stateService.Stub(x => x.GetTaxRate(State.Florida))
        .Return(0.6);
    municipalService.Stub(x => x.GetSurchargeRate(Municipality.OrangeCounty))
        .Return(0.05);

    // run what's being tested
    decimal result = new SalesTaxCalculator().CalculateSalesTax
        (10m, State.Florida, Municipality.OrangeCounty);

    // verify the expected behaviour (these are the specifications)
    [Test]
    public void should_check_the_state_sales_tax_rate()
    {
        stateService.was_told_to(x => x.GetTaxRate(State.Florida)); // extension methods wrap assertions
    }

    [Test]
    public void should_check_the_municipal_surcharge_rate()
    {
        municipalService.was_told_to(x => x.GetSurchargeRate(Municipality.OrangeCounty));
    }

    [Test]
    public void should_return_the_correct_sales_tax_amount()
    {
        result.should_be_equal_to(10.65m);
    }
}
2
Jay

FlexでのBDDテストについては、GivWenZen-flexを試してみてください http://bitbucket.org/loomis/givwenzen-flex 。

乾杯、クリス

0
Kris

適切に実装されたxBehaviorBDDテストは、ロボ主導のユーザー受け入れ基準です。

x仕様BDDテストは通常​​、単体テストであり、ユーザーの受け入れ基準として受け入れられる可能性はほとんどありません。

0
Chris Marisic