ユニットテストを手作業で書くのは例による証明ですか？

JUnitテストの記述は、コードを介した1つの特定のパスを示すことを知っています。

私の仲間の一人がコメントしました：

単体テストを手動で作成することは、例による証明です。

彼は、Quickcheckのようなツールと型を使用したプログラムの動作を推論する機能を備えたHaskellのバックグラウンドから来ていました。

彼の含意は、あなたのコードがテストされていないこの方法で試されない他の入力の組み合わせがたくさんあるということでした。

私の質問は次のとおりです。手動でユニットテストを記述しているかどうかは、例によって証明されますか？

テスト用の入力をランダムに選択している場合、Proof By Exampleの論理的誤りを実行している可能性があると思います。

しかし、優れた単体テストはそれを行うことはありません。代わりに、範囲とエッジケースを扱います。

たとえば、整数を入力として受け入れる絶対値関数の単体テストを作成する場合、コードが機能することを証明するために入力のすべての可能な値をテストする必要はありません。包括的なテストを取得するには、5つの値（-1、0、1、および入力整数の最大値と最小値）のみが必要です。

これらの5つの値は、関数のすべての可能な範囲とエッジケースをテストします。関数がすべての入力値に対して機能する高い信頼水準を得るために、他のすべての可能な入力値（つまり、整数型が表すことができるすべての数値）をテストする必要はありません。

任意のソフトウェアテストは、「例による証明」、JUnitのようなツールを使用してテストするだけでなく、ユニットのようなものです。そして、それは新しい知恵ではありません、1960年のダイクストラからの引用があります、それは本質的に同じことを言います：

「テストは、バグがないことではなく、存在を示します」

（「shows」という単語を「proofs」に置き換えてください）。ただし、これはランダムなテストデータを生成するツールにも当てはまります。現実世界の関数の可能な入力の数は、通常、ケースの生成方法とは無関係に、生成され、宇宙の時代内の期待される結果に対して検証できるテストケースの数よりも桁違いに大きいため、大量のテストデータを生成するためにジェネレーターツールを使用しても、特定のバグを検出した可能性がある1つのテストケースを見逃さないという保証はありません。

ランダムなテストがあり、時々手動で作成したテストケースで見落とされたバグを明らかにしました。ただし、一般的には、テストする関数のテストを慎重に作成し、できるだけ少ないテストケースで完全なコードとブランチカバレッジを取得できるようにする方が効率的です。手動で生成されたテストとランダムに生成されたテストを組み合わせることが実現可能な戦略になる場合があります。さらに、ランダムテストを使用する場合、再現可能な方法で結果を取得するように注意する必要があります。

したがって、手動で作成されたテストは、ランダムに生成されたテストよりも悪くはありません。

手動でテストを書くことは「例による証明」です。しかし、QuickCheckや、限られた範囲のタイプのシステムも同様です。正式な検証ではないものはすべて、コードについての説明が制限されます。代わりに、アプローチの相対的なメリットの観点から考える必要があります。

QuickCheckのような生成テストは、広い範囲の入力をスイープするのに非常に適しています。また、手動テストよりもエッジケースに取り組む場合の方がはるかに優れています。生成テストライブラリは、これよりも経験豊富です。一方、特定の出力ではなく、不変量についてのみ説明します。そのため、プログラムが正しい結果を得ていることを検証するには、実際にそれを検証するための手動テストが必要foo(bar) = bazです。