このような単一の条件を持つ簡単な方法があります。
if (String.IsNullOrEmpty(FirstName))
{
成功 = false;
}
成功を返します。
Pex を実行すると、FirstName プロパティに Null を割り当て、FirstName に "\0" を割り当てるテスト ケースが 1 つだけ生成されます。
string.Empty を FirstName プロパティに割り当てる 3 番目のメソッドを生成しないのはなぜですか?
このような単一の条件を持つ簡単な方法があります。
if (String.IsNullOrEmpty(FirstName))
{
成功 = false;
}
成功を返します。
Pex を実行すると、FirstName プロパティに Null を割り当て、FirstName に "\0" を割り当てるテスト ケースが 1 つだけ生成されます。
string.Empty を FirstName プロパティに割り当てる 3 番目のメソッドを生成しないのはなぜですか?
私が理解しているように、Pex はアプリケーション コードで 100% のテスト カバレッジを達成しようとします。あなたが投稿したコードから、そのメソッドのすべてのブランチをトレースするのに 2 つのテストしかかからないでしょう。
Pexは.Netライブラリの内部を調べるように構成されていないので、空の文字列がIsNullOrEmpty
関数の特別な値になるかどうかはわかりません。ヌル文字とヌル文字('\ 0')は、文字列がどのように使用されているかを調べることができない場合に、文字列をテストするための2つのお気に入りの選択肢です。
必要に応じて、パラメータ化された単体テストを作成して、空の文字列をチェックできます。
Joshua Dale が言うように、Pex はできるだけ多くのコード ブランチをカバーするテストを生成しようとします。Pexリファレンスマニュアルの最初の段落にあるように:
メソッドが与えられると、[原文のまま] Microsoft Pex は、さまざまなコード パスを実行する入力を生成します。つまり、Microsoft Pexは、最大のコード カバレッジを実現するテスト スイートを生成することを目的としています。
(ご覧のとおり、このドキュメントは校正を行うことで十分です!)
これを念頭に置くことが重要です。そのため、Pex はすべてのコード ブランチを実行するように設計されたテスト入力を生成し、セマンティック値を含むテスト入力を生成しません (それが一般的な場合を想定してください)。これを認識することが重要であり、Pex が生成するテスト スイートが、考えられるすべての障害条件をテストがカバーしていることを意味すると想定しないことが重要です。テスト入力はエッジ ケース (null/null 文字など) にヒットするように設計されています。これは、目的ができるだけ多くのコード ブランチを実行することであると考えれば明らかです。
Pex は、独自のテストで検出されないコード ブランチを探索しようとします。それはあなたの知性を補完するものです。人間として、コードが何をすべきかを理解するのが得意であり、チューリング マシンとして、Pex はすべての可能なコード ブランチを選択するのが得意です (ただし、多くの場合、助けが必要です)。