プロパティベースのテストを実装する際に、前提条件式より入力ジェネレータを使用する必要があるのはいつですか？

Question

プロパティベースのテストを実装する場合、入力ジェネレータを前提条件式で使用する必要がありますか？

特定のオプションを選択する際にパフォーマンスに関する考慮事項はありますか？

内部的には、一方のメソッドは必然的に他方のメソッドを使用しますか？

前提条件の式が入力ジェネレータと比較して実行に時間がかかると思います。誰かがこれをテストしましたか？

私たちはなぜ両方必要でしょうか？

Answer 1

前提条件式（FsCheckの==>演算子など）を使用すると、基本的にデータが破棄されます。これが100のケースのうちの1つでしか発生しない場合でも、（FsCheckではデフォルトの実行回数が100であるため）通常のプロパティに対して1つの入力セットを放棄しています。

100のうち1つを投げ捨てることは、おそらく大したことではありません。

ただし、さらに多くのデータを捨てることがあります。たとえば、正の数値だけを必要とする場合は、x > 0のような前提条件を書くことができますが、FsCheckは負の数も生成するため、生成後にすべての値の50％を捨ててしまいます。これは、テストの実行速度を低下させる可能性があります（ただし、パフォーマンス上の考慮事項についてはいつものように）。

FsCheckには正にそのための組み込みジェネレータが付属していますが、this exampleのように、可能な入力値の範囲をより詳細に制御する必要があることがあります。

FizzBuzz kataを行う場合、例えば、あなたがwrite your test for the FizzBuzz case like thisことがあります。

[<Property(MaxFail = 2000)>] 
let ``FizzBuzz.transform returns FizzBuzz`` (number : int) = 
    number % 15 = 0 ==> lazy 
    let actual = FizzBuzz.transform number 
    let expected = "FizzBuzz" 
    expected = actual 

はMaxFail財産の使用を注意してください。あなたがそれを必要とする理由は、その前提条件が15人の候補者のうち14人を捨て去るからです。デフォルトでは、FsCheckはあきらめる前に1000人の候補者を試しますが、15人の候補者を15人も捨てると、平均して前提条件に合った67個の値しか得られません。 FsCheckのデフォルトの目標はプロパティを100回実行することであるので、それはあきらめます。

MaxFailプロパティの意味するところでは、デフォルトを調整することができます。 2000人の候補者では、133件の前提条件の一致が平均的に予想されます。

それはしかし、特に効果的な感じがしないので、あなたは、代わりにカスタム・ジェネレータを使用することができます。これは、an ad-hoc in-line Arbitraryを使用しています

[<Property(QuietOnSuccess = true)>] 
let ``FizzBuzz.transform returns FizzBuzz``() = 
    let fiveAndThrees = 
     Arb.generate<int> |> Gen.map ((*) (3 * 5)) |> Arb.fromGen 
    Prop.forAll fiveAndThrees <| fun number -> 

     let actual = FizzBuzz.transform number 

     let expected = "FizzBuzz" 
     expected = actual 

を。これは、データが破棄されないため、より効率的です。

私の気持ちは、もしそれがonly throw away the occasional unmatching inputなら前提条件を使うことです。ほとんどの場合、私はカスタム発電機を好む。