47

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

4

7 に答える 7

126

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

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

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

受け入れテストは、実際には会話を強制するものではなく、通常、作成しているテストが適切なテストであるという前提に基づいて機能します。BDD では、自分が何をしているのかわからないと仮定します (そして、おそらく自分が知らないことを知らないと思います)。これが、シナリオやユニットレベルの例について会話できるように、「Given, When, Then」などを使用する理由です。(これらは、ほとんどの人がよく知っている 2 つのレベルです。受け入れテストと単体テストに相当しますが、規模が大きくなります)。

ビジネスパーソンに「私の受け入れテストを手伝ってください」と頼むことはできないので、私たちはそれらを「受け入れテスト」とは呼びません。彼らは本当に奇妙で目を細めた目であなたを見て、あなたをそのオタクの女の子として片付けます. あなたの 93% はそれを望んでいません。

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

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

それを本当に正しく行う唯一の方法は、すべての要件を前もって把握することです。それは正しい。ウォーターフォールです。残業を覚えていますか？週末の仕事？あなたが作成したものが 1 つも製品化されなかった 7 年間は? それを避けたいのであれば、チャンスは 1 つしかありません。自分が間違っていると仮定し、それについて少し話し合って間違いを減らし、それでもまだ間違っていることを受け入れて、とにかくそれを実行することです。テストの作成が早すぎると、間違いを犯す可能性がさらに高くなります。変更するのが難しくなり、誰もがあなたが正しいと考え、PM があなたのベロシティを測定しているため、あなたはさらに 2 週間間違っていることにコミットしています。さらに悪いことに、あなたは自分のことをテストしようとしています」

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

ツールに固執しないでください。ツールは、会話をキャプチャし、それらがコードに反映されるようにするためのメカニズムにすぎません。シナリオは会話に取って代わるものではなく、3 x 5 のインデックス カード以上のものは要件に取って代わるものです。

そうは言っても、ツールから始めなければならない場合は、Fit のテーブルや備品を台無しにすることなく、Given / When / Then を素敵に実行できるように、Slim を Fitnesse の後ろに置いてください。GivWenZenは Slim に基づいており、どちらも優れています。FitSharp は、.NET スペースのユーザーに相当します。または、Cucumber や SpecFlow を使用するか、何年も問題なく機能する小さなカスタム DSL*を作成します。

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

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

于 2010-11-22T18:41:50.387 に答える
5

厳密に言えば、「BDDテスト」のようなものがあるかどうかはわかりません。BDD は、複雑なプロジェクトを完了するために利害関係者とどのように対話し、協力するのが最善かを提案する哲学です。テストを書くための最善の方法を直接指示するものではありません。言い換えれば、BDD 哲学プロジェクトの下で、おそらくすべての通常の種類のテスト (受け入れテストを含む) を引き続き行うことができます。

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

于 2009-04-20T08:46:59.827 に答える
2

BDD は単なるテストの範囲よりも大きいですが、実際には BDD テストがあります。これらのテストは、BDD 言語に準拠した単体テストです。

いくつかの初期コンテキスト (与えられたもの) が与えられると、イベントが発生したときに、いくつかの結果が保証されます。

好みの言語に応じて、いくつかの優れた BDD フレームワークを利用できます。 Java のJBehave Ruby のRSpec .NETのNBehave

于 2009-05-13T18:38:29.260 に答える
2

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

それがどのように機能するかを理解するには、JBehaves 2min tutorialをお勧めします。

于 2009-09-03T06:36:33.110 に答える
2

私は「仕様」と「テスト」を区別したいと思っています。

というメソッドをカバーする場合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);
    }
}
于 2009-08-13T05:17:19.283 に答える
0

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

xSpecification BDD テストは通常​​単体テストであり、ユーザーの受け入れ基準として受け入れられる可能性は低いです。

于 2011-12-08T17:27:25.050 に答える
0

Flex での BDD テストについては、GivWenZen-flex を試すことができますhttp://bitbucket.org/loomis/givwenzen-flexをチェックしてください。

乾杯、クリス

于 2010-06-25T21:48:38.870 に答える