11

多くのプロパティを持つクラスを使用しています。例えば;

public class Bib
{        
    public int PartQty { get; set; }
}

次に、単体テストを行います。私はxUnitテストを次のように行いました

    [Fact]
    public void CanGetAndSetPartQuantity()
    {
        const int expected = 3;

        var target = new Bib() {PartQty = expected};

        Assert.Equal(expected, target.PartQty);
    }

ここで、expected = 3 をハードコーディングする方法が嫌いです。アクセサとミューテータについてこのプロパティをテストする良い方法は何ですか?

4

8 に答える 8

16

このプロパティには、整数のゲッター/セッター以外の動作がないため、基本的には、コンパイラが機能することをテストしているだけです。これは基本的にテストに何の価値も追加しません。完全に削除することを検討してください。そうすれば、この奇妙な状況から解放されます。:)

キャプチャしようとしている動作 (許可された境界条件など) がある場合は、それらをテストするだけでよく、他には何もありません。通常、これらの境界条件の定数は、オブジェクトの一部として使用できます。これらの定数の使用を検討してください。+/- 適切な増分です。

于 2011-05-03T23:18:05.330 に答える
9

制約付き非決定性は、この種の単体テストに適しています。代わりに次のように書きます。

[Fact]
public void CanGetAndSetPartQuantity()
{
    const int expected = new Random().Next();

    var target = new Bib() {PartQty = expected};

    Assert.Equal(expected, target.PartQty);
}

これにより、入力が何であれ、出力が入力を正しく表すことが保証されます。

于 2011-05-04T07:33:52.610 に答える
6

私は単体テストを「ホワイトボックス」テストにすることを固く信じています。つまり、既知のコーナーケースを使用してテスト入力を選択することが許可されています。この特定のケースでは、auto-property を使用して、コンパイラを信頼する場合、テストは不要です。コンパイラが期待どおりに自動プロパティを実装することを信頼できない場合は、記述したとおりにテストを実行することも信頼できません。

つまり、より複雑なセッターを使用している場合は、考えられる失敗のケースに基づいて入力を選択します。いくつかの典型的なケース:

  • >= 0 を検証するプロパティの負の数
  • その他の検証の失敗
  • Int.MaxValue のような極端な境界ケースでは、セッターでオーバーフローや予期しない動作が発生することがあります
  • 検証に合格する必要がある任意の値 (「適切な」ケースであることがわかっている限り、ここで値を選択する方法に関する実際のガイダンスはありません)。
于 2011-05-03T23:18:40.813 に答える
2

テストは、ある種のユースケースから導き出す必要があります。面白いことに、最初にクラスを紹介し、次にTDDに逆行するテストの作成について話しました。

ユースケースはテストに通知し、テストはコードに通知します。あなたのユースケースが「私のAPIのユーザーがPartQty任意の整数に呼び出されるプロパティを設定し、常に設定した整数を取り戻すことができる」ということは非常に疑わしいです。int.MaxValueそれが実際のユースケースである場合は、とをチェックする単体テストを作成しますint.MinValue。ただし、これらが実際の値になることはめったにありません。

実際のユースケースは次のようになります。「私のAPIのユーザーは、インジェクションをBib通知し、を4IFlugleBinderに設定してから、メソッドを呼び出します。これにより、インスタンスのメソッドが4回呼び出されます。」それがユースケースである場合、テストは非常に異なって見えます。PartQtyExecuteBindIFlugleBinder

Bib正直なところ、それはある種のDTOにすぎないように見えます。私の経験では、ほとんどのDTOは、より高いレベルのユースケースの成果物にすぎません。APIが提供する関数呼び出しの結果としてDTOが返される場合は、実際にはインターフェイスを返す必要があり、DTOクラス自体はプライベートである必要があります。この場合、明示的にテストする必要はありません（プロパティをテストするだけです）。メソッド呼び出しから得られる実際の結果の）。同様に、公開されていない内部DTOの場合は、公開しないでください。ユーザーが値のバンドルを提供する必要がある場合は、APIがインターフェースを受け入れる必要があります。次のように、ユーザーがインターフェイスを実装する独自のクラスを定義するか、不変のクラスを提供できるようにします。

public class Bib : IBib
{
    public Bib(int partQty)
    {
        PartQty = partQty;
    }
    public int PartQty { get; private set; }
}

次に、ペダンティックになりたい場合にコンストラクターが機能するかどうかを確認するテストを作成できますが、それほど重要ではありません。

于 2011-05-04T13:44:59.843 に答える
2

これは役立つはずです...

[Fact]     
public void CanGetAndSetPartQuantity()     
{
    bool fail = false;
    int expected = 0;

    while (!fail && expected < int.MaxValue)
    {
        var target = new Bib() {PartQty = expected};          
        fail = expected != target.PartQty;
        expected++;
    }

    Assert.IsTrue(!fail);
}
于 2011-05-03T23:38:06.707 に答える
2

これは「退屈するまでテストする」カテゴリに分類されると思いますが、テストする価値があると本当に感じている場合は、承認テストが非常に簡単なテスト方法を提供します。プロパティを確認するための簡単なテストが添付されています。

[TestMethod]
[UseReporter(typeof(DiffReporter))]
public void TestMethod1()
{
    var fred = new Person{
            Age = 35,
        FirstName = "fred",
        LastName = "Flintstone",
        Hair = Color.Black
           };
    Approvals.Verify(fred.WritePropertiesToString());
}

これにより、次のようなファイルが生成されます。

Person
{
    Age: 35
    FirstName: fred
    LastName: Flintstone
    Hair: Color [Black]
}

そのファイルの名前を .approved に変更するだけで完了です。

拡張メソッドの使用に注意してください: .WritePropertiesToString()

承認試験の基本に関するビデオはこちら

MsTest: http://www.youtube.com/watch?v=bg8GOmlwqYY

ヌユニット: http://www.youtube.com/watch?v=aO_fyZBxaFk

Xunit: http://www.youtube.com/watch?v=8wPx0O4gFzc

于 2012-04-24T16:21:24.547 に答える
2

少し前に、良い単体テストの実践に関するプレゼンテーションを行いました (申し訳ありませんが、私の脆弱な記憶から抜け出した人の名前です)。彼は、そのような値を、慎重に選択された名前の定数に格納することを提唱しました。

あなたの場合、私は次のような名前を使用します

const int SomeRandomValidPartQuantity=3;

これにより、この値を正確に使用する意図を示します。この場合、有効な数量の直後です。

于 2011-05-04T13:33:41.650 に答える