29

はい、「Sum」や「Divide」などの関数の境界値に関するテストを生成することは可能です。ここでは、Pex が優れたツールです。

しかし、多くの場合、ビジネス行動に関するテストを作成します。古典的な Beck の tdd book の例を考えてみましょう:

[Test]
public void ShouldRoundOnCreation()
{
  Money money = new Money(20.678);
  Assert.AreEqual(20.68,money.Amount);
  Assert.AreEqual(2068,money.Cents);
}

このテストは生成できますか? いいえ:)私のプロジェクトのテストの95％はビジネスロジックをチェックしており、生成できません。

Pex (特に Moles と組み合わせて) は 100% のコード カバレッジを提供できますが、テスト スイートの高いコード カバレッジ率は、コードが十分にテストされていることを示すものではなく、すべてがテストされているという誤った信頼を与えるだけです。そして、これは非常に危険です。

問題は、Pex は本当に便利なツールなのかということです。

4

2 に答える 2

30

Pex の使用方法が間違っていると思います。パラメーター化された単体テストでアサーションを記述することを強くお勧めします。

アサーションを記述すると、Pex は体系的にそれらを無効にしようとします。ここで Pex の力が発揮されます。アサーションを記述すればするほど、バグを見つけようとします。

Pex を使用して、アサーションを記述せずにコード カバレッジの高いテスト スイートを取得すると、コード カバレッジと保証されたランタイム例外という、要求されたものだけが得られます。Pex は「のみ」ブランチをカバーしようとします (1 アサーション = 1 ブランチ)。カバーするブランチがない場合 (アサーションなし)、興味深いテスト ケースは生成されません。

一般に、パラメーター化された単体テストでアサーションを書くことは、より一般的であるため、書くのが難しくなります。丸めの動作から始めましょう。丸めの発生を許可する境界は確かにあり、これは自然にパラメーター化された単体テストに変換されます。

[PexMethod]
public void RoundInBounds(double value) 
{
    var money = new Money(value);
    // distance between value and amount should be at most 0.01/2
    Assert.AreEqual(value, money.Amount, 0.005);
}

それらを書くために使用できる多くのパターンもあります。たとえば、「Money」クラスはおそらく冪等です。Money インスタンスで「Amount」の値をフィードバックすると、Amount が返されます。これは、パラメータ化された単体テストにエレガントに変換されます。

[PexMethod]
public void RoundIsIdempotent(double value) 
{
     var first = new Money(value).Amount;
     var second = new Money(first).Amount;
     Assert.AreEqual(first, second, 0.0001);
}

また、パラメーター化された単体テストは間違いなく TDD の世界に属していることにも注意してください。最初にパラメーター化された単体テストを作成するだけで、Pex は失敗したバグを見つけ、バグを修正し、Pex は次の失敗したバグを見つけます。

これにより、Pex は便利なツールになりますか? あなたが裁判官になります。

于 2010-04-25T04:07:39.867 に答える
3

Pexにはいくつか便利なものがあります。

  1. コードカバレッジ。Pexを少し脇に置いておきましょう。一般に、100％のコードカバレッジは、必ずしも適切なコードカバレッジがあることを意味するわけではありません。これは、パスが実行されることを意味しますが、プログラムにはデータフローがあり、そのコードの異なる追加入力をテストすると、コードカバレッジではないにしても、最高の「テストカバレッジ」が得られます。これが、あなたの主張を繰り返しているだけです。100％のコードカバレッジは必ずしも良いとは限りませんが、25％のコードカバレッジは悪いと言えます。そのため、コードカバレッジは便利です。コードカバレッジが低い場合は、テストカバレッジが低いことが確実にわかります。

    Pexを使用して100％のコードカバレッジを取得する場合、それ自体は実際にはより良いテストカバレッジを取得するのに役立ちませんが、それが行うことは、デバッガーに使用できるテストを本番コードの一部に与えることです。実際、会議としてのPexプレゼンテーションは、まさにこの目的のためのPexの使用を示しています。プログラマーは、「ねえ、NHibernateでこのメソッドを見てください。デバッガーでこのメソッドをステップスルーして、その機能を確認したいのですが、通常の「ビジネスエントリポイント」からそのメソッドを呼び出すにはどうすればよいですか。ライブラリについて何も知らなければ、できません。そこで、彼はPexを実行し、あらゆる種類のパラメータを使用してコードをステップ実行することができました。興味深い、はい。便利かもしれませんが、そうでないかもしれません。

  2. Pexは、自動的に作成されたテストに加えて、テストのパラメーター化にも役立ちます。データ駆動型の単体テストを作成することをお勧めします。異なるパラメータを使用して、同じコードを何度も書くのはなぜですか。一度書き込んで、データソースからパラメータをフィードします。

  3. Pexは、単純なスタブフレームワークとしても役立ちます。新しいラムダ式を使用してモックオブジェクトを作成するのがおそらく最も簡単な方法です。これは、RhinoMocksなどの複雑なフレームワークよりもはるかに理解しやすいものです。Molesを使用すると、インターフェイスだけでなく、クラス内の具体的な非仮想メソッドをスタブすることもできます。

  4. また、「ビジネスロジックでのテスト」レイヤーにも注意しすぎます。ユニットテスト用ではないBehavioralDrivenDevelopmentを簡単に実行できます。そこで、スペックに対してテストしています。それだけだとしたら、たとえば、ビジネス上の価値はないが、アプリケーション全体で使用される内部ライブラリであるカスタムデータ構造などをどのようにテストしますか。

于 2010-04-24T23:29:53.733 に答える