問題タブ [property-based-testing]

小さなサンプル アセンブリでxUnitを動作させることができました。ここで、 FsCheckも理解できるかどうかを確認したいと思います。私の問題は、関数のテスト プロパティを定義するときに困惑していることです。

関数の良いサンプル セットを持っていないだけかもしれませんが、たとえば、これらの関数の良いテスト プロパティは何でしょうか?

さまざまな機能ベースの言語には、プロパティ ベースのテストを可能にするツール ( Quickcheck など) があります。

PHPでプロパティベースのテストを行うにはどうすればよいですか?

PHP メソッドの in および output プロパティを指定して、カバレッジ テストを実行できるようにしたいと考えています。

何年も前に、 Agitarと呼ばれる Java テスト ツールが人気を博しました。プロパティベースのテストのようなことをしているように見えました。

最近では、 Haskell の Quickcheckに基づくプロパティ ベースのテストが一般的です。Java には、次のような多数のポートがあります。

• クイックチェック
• jcheck
• junit-クイックチェック

私の質問は: Agitar と Quickcheck プロパティベースのテストの違いは何ですか?

ScalaTestを使用して、基本的に「例外をスローしないか、可能な例外のリストの1つをスローする必要がある」と述べているプロパティを作成しようとしていますGeneratorDrivenPropertyChecks。問題は、 を論理和と組み合わせることができなかったことですnoException。したがって、私ができる最善の方法は、この醜いテストです。

代わりに私が見たいのは、次のように読むことです

プロパティテストは何を目指しているのか、スイートポイントは何なのか、どこで使うべきなのか知りたいです。テストしたい関数の例を見てみましょう:

この関数 はf、数値のリストを取り、奇数を 2 乗し、偶数を除外します。次のように、関数に関するいくつかのプロパティを述べることができます

1. 偶数のリストを指定すると、空のリストを返します。
2. 奇数のリストを指定すると、結果リストは入力と同じサイズになります。
3. 偶数のリストと奇数のリストがあるとすると、それらを結合し、シャッフルして関数に渡すと、結果の長さは奇数のリストの長さになります。
4. 正の奇数のリストを指定すると、同じインデックスにある結果リストの各要素は元のリストよりも大きくなります
5. 奇数と偶数のリストを提供し、それらを結合してシャッフルすると、各番号が奇数のリストが得られます
6. 等

関数が最も単純なケースで機能することをテストするプロパティはありません。たとえば、f間違って実装した場合にこれらのプロパティを渡す単純なケースを作成できます。

したがって、単純なケースをカバーしたい場合は、プロパティ仕様でアルゴリズムの基本的な部分を繰り返すか、値ベースのテストを使用する必要があるようです。私が持っている最初のオプションは、アルゴリズムを繰り返すのに役立つかもしれません。たとえば、速度のためにアルゴリズムの実装を変更する予定がある場合は、アルゴリズムを改善する予定です。このようにして、再度テストするために使用できる参照実装ができました。

いくつかの些細なケースでアルゴリズムが失敗しないことを確認したい場合、および仕様でアルゴリズムを繰り返したくない場合は、単体テストが必要なようです。たとえば、これらのチェックを記述します。

今では、アルゴリズムに自信を持っています。

私の質問は、プロパティ ベースのテストは単体テストに取って代わるものですか、それとも補完的なものですか? プロパティをどのように記述するかという一般的な考え方はありますか?それらは便利ですか、それとも関数のロジックの理解に完全に依存していますか? つまり、何らかの方法でプロパティを記述することは特に有益であると言えますか?

また、プロパティがアルゴリズムのすべての部分をテストするように努力する必要がありますか? アルゴリズムから 2 乗を除外して、別の場所でテストし、プロパティでフィルタリング部分だけをテストして、それが適切にカバーされているかどうかをテストすることができます。

そして、単体テストを使用して合格し、他Prelude.idの場所をテストできます。g

私はいくつかの古いユニット テストをプロパティ ベース テスト (PBT) に置き換えようとしてscalaいscalatest - scalacheckます。テストしたいメソッドがある場合、単純化された状況は次のとおりです。

通常、次のような単体テストを作成します。

したがって、テストごとに、期待する出力を書きますが、問題ありません。さて、PBT では、次のようになります。

すべての入力に対して true になるテストを作成しようとすると、テストでStringメソッドのロジックを再度作成する必要があることに気付きます。この場合、テストは次のようになります。

つまり、出力が正しいことを確認するために、テストで実装を作成する必要がありました。これから抜け出す方法はありますか？私は PBT を誤解していますか?代わりに、次のような他のプロパティをテストする必要があります。

• 「文字列はオリジナルと同じ長さでなければなりません」
• 「文字列には元のすべての文字が含まれている必要があります」
• 「文字列に小文字を含めないでください」...

それももっともらしいですが、かなり不自然で明確ではないように思えます。PBT の経験が豊富な人は、ここで光を当てることができますか?

編集: @Eric のソースをたどってこの投稿にたどり着きました。(カテゴリの適用でもう一度times): ( F#)内のメソッドをテストするために 、まさに私が意味することの例があります:

著者は、最終的に次のようなテストを作成します。

したがって、そのメソッドをテストするために、メソッドのコードがテストで複製されます。この場合、乗算と同じくらい些細なことですが、より複雑なケースに推定されると思います。

例ベースのテストを使用した TDD について一部の開発者が主張する 1 つの警告は、すべての有効な入力処理が欠如している可能性があることです。

これらの開発者が主張できる簡単な例を見てみましょう。

2 つの数を加算するプログラムを作成します。

開発者のボブは、最初のテストを書き始めます:
1 + 3 が与えられた場合、結果は 4です。
実装: def add(x: Int, y: Int) = 4
いいね、パス。

2 番目のテスト:
2 + 2 を指定すると、結果は 4 になります。実装は同じです: def add(x: Int, y: Int) = 4

そのため、他の開発者がやって来て、彼に次のように言いました。

「ボブは、例ベースのテストでは不十分な 2 つの例では不十分であることがわかりました。
すべての出力をテストしたわけではなく、実際の実装を見ると、結果が 4 と異なる他の入力では失敗するでしょう!
さあ、聞いてください。すべての有効な入力をカバーするために、いくつかのプロパティベースのテストを書き始めます。
それでは、加算に固有の可換性テスト、結合性などから始めましょう: 加算のプロパティ!"

でもでもでも…。 ボブのTDDの練習は本当に悪いです！確かに、彼は三角測量
を適用したかったのですが、実装を変更する必要がなかったため、すでに成功したテストを書きました!

Triangulation に導くには、失敗するテストを書く必要があります。そして三角測量は、TDD の実践の主要な鍵の 1 つです。
これにより、主なステップであるリファクタリングが可能になります。これは、2 つの異なる結果につながる 2 つのパスを管理する必要があるためです。

=> テストが具体的になる限り、コードはリファクタリングのおかげでより一般的になります。

私の質問は次のとおりです:
三角測量の優れたプラクティスで厳密な TDD を実践する場合、99% のケースで既に優れた TDD でカバーされている不変条件を主張して、プロパティベースのテストを使用することの本当の利点は何ですか?
確かに、開発者が優れた IQ を持ち、理にかなった実装を構築すると仮定すると ;)

私の例はそれらのスライドから取ったものです。

ScalaTest でプロパティ ベースのテストを行っていますが、次のコードがありました。

コードを実行するforAllと、同じ値が複数回試行されていることに気付きました。

上記のコードを考えると、各値をoneOf一度だけ試行する方法があるかどうか疑問に思っていました。つまり、ScalaTest が同じ値を 2 回使用しないようにするためです。

などの他のジェネレーターを使用したとしてもGen.alphaStr、同じ String を 2 回テストしないようにする方法を見つけたいと思います。私がこれを行うことに興味があるのは、各テストが異なるプロセスで実行されているサーバーに対して実行されるためです。そのため、多少のコストがかかるため、同じことを 2 回テストすることは避けたいと考えています。

私は FsCheck とランダム プロパティ ベースのテストへのパラダイム シフトを試みています。列挙しきれないほど多くのテスト ケースを含む複雑なビジネス ワークフローがあり、ビジネス ロジックは新しい機能が追加されて移動するターゲットです。

背景: マッチメイキングは、エンタープライズ リソース プランニング (ERP) システムで非常に一般的な抽象概念です。注文処理、サプライ チェーン ロジスティクスなど

例: C と P が与えられた場合、2 つが一致するかどうかを判断します。任意の時点で、一部の P は決してMatch-able ではなく、一部の C は決してMatch-able ではありません。それぞれに、試合の対象と見なされるかどうかを示すステータスがあります。

ボーナス: 単純な「ブロック マッチ」ステータスを超えて、C と P にはそれぞれ一連のチェックがあります。CがMatch-edであるためにいくつかのチェックが真でなければならず、PがMatch-edであるためにいくつかのチェックが真である必要があり、CのいくつかのチェックがPのチェックに対してクロスチェックされなければなりません。 FsCheck を使用したテストは、(a) 製品に追加された新機能の例であり、(b) 次のようなテスト (ユーザー操作) を作成できる可能性があるため、大きな利益をもたらします。

1. 作成
2. 作成後、パイプラインを進めます
3. 前に戻る (許可されている場合と許可されていない場合はいつですか? 例: 有料注文はおそらく購入承認ステップに戻ることはできません)
4. パイプラインの途中で (チェックなど) を追加/削除する
5. 同じ C と P の Match を 2 回 (たとえば、PLINQ と同時に) 作成するように依頼した場合、重複が作成されますか? (ユーザーに返されるメッセージは何ですか?)

私が苦労していること：

1. FsCheck のテスト データはどのように生成すればよいですか? 正しい方法は、Match を作成するための C と P の個別の可能な組み合わせをすべて定義し、それらをモデルベースのテストの「事前条件」にし、事後条件を Match を作成するかどうかにすることだと思いますが、...
2. それは本当に正しいアプローチですか？ランダム化されたプロパティ ベースのテスト ツールとしては決定論的すぎると感じます。このような状況で FsCheck を使用するのは過剰設計ですか? すると、シード値を無視して決定論的なテスト データのストリームを返すデータ ジェネレーターを持っているかのようになります。
3. この時点で、FsCheck ジェネレーターは、xUnit.net や AutoPOCO のようなものを使用することと何か違いがありますか?

この簡単な例を考えてみましょう:

• オブジェがPersonある
• 次のいずれかが必要です:FirstNameおよびLastName(または両方、ただし一方は必須)
• 有効なAge値 (整数、0 から 150 の間)が必要です

この単純なケースをどのようにプロパティ ベース テストしますか?