8

非常に手間がかかるように見えますが、規則に従って、自動実装されたプロパティをテストする必要がある場合は、公開されているものをすべてテストする必要がありますか?

顧客クラス

public class Customer
{
    public string EmailAddr { get; set; }
}

テスト済み

[TestClass]
public class CustomerTests : TestClassBase
{
    [TestMethod]
    public void CanSetCustomerEmailAddress()
    {
        //Arrange
        Customer customer = new Customer();

        //Act
        customer.EmailAddr = "foo@bar.com";

        //Assert
        Assert.AreEqual("foo@bar.com", customer.EmailAddr);
    }
}
4

5 に答える 5

10

私は通常、アクションを実行していないコードはテストする価値がないと考えています。これは通常、値を設定または返すだけなので、プロパティ (自動実装かどうか) をテストしないことを意味します。

これは、プロパティのゲッターまたはセッターが何らかの「作業」を実行する場合に変更されます。たとえば、他のフィールド/プロパティ/その他の状態に基づいて 2 つ (またはそれ以上) の値のうちの 1 つを返す可能性があります。

まだ読んでいない場合は、Roy Osherove の Unit Testing に関する本を強くお勧めします。これを含め、「何をいつテストするか」に関するあらゆる種類の質問に対処します。

于 2010-06-17T21:14:12.730 に答える
8

自動実装されたプロパティからまったく異なるものに切り替えるとどうなりますか? 実装を知っているため、テストが冗長に見えるだけです。テストを書くときに考慮すべきではありません。

もちろん、これは実際に実装をすぐに変更する可能性に依存します。

于 2010-06-17T21:13:16.173 に答える
1

設定のテストとプロパティの取得は、オブジェクトのビジネス機能をテストするコンテキストで行う必要があります。プロパティをテストするビジネス機能がない場合は、プロパティが不要であるか、さらにテストが必要です。テストを作成する前にプロパティを追加するのではなく、プロパティを必要とするテストを追加するときにプロパティを追加することをお勧めします。

ビジネス機能をテストすることで、単体テストの観点から、コードをブラックボックスのように扱うことになります。これにより、テストへの影響をはるかに少なくして、実装の詳細を下で切り替えることができます。リファクタリングはTDDサイクルの重要な（そして見過ごされがちな）段階であるため、これはコード編集が大幅に少なくなることを意味します。また、（たとえば）プロパティにはパブリックセッターがなく、検証やその他のビジネスロジックを実行するメソッドによって割り当てられる必要があることに気付くかもしれません。

于 2010-06-18T01:55:19.773 に答える
1

API が予想される一連のプロパティに準拠していることをテストするのか、それとも、お見せしたように、プロパティへのアクセスと設定をテストするだけなのかによって異なります。

あなたが与える例では、私はノーと言います。

アップデート

期待される API に準拠しています。たとえば、リフレクション/動的環境でプロパティに間接的にアクセスしており、プロパティとメソッドのアクセス呼び出しを使用して、未知の API が期待される API に準拠していることを確認する場合。

于 2010-06-17T21:10:05.960 に答える
0

単体テストは、アプリケーションに実装している機能のテストに限定する必要があります。

アプリケーションが依存する API/SDK をテストしないでください。部分的には時間の無駄です (あなたの会社は X-Third-Party の SDK/API をテストするためにあなたにお金を払いたいですか?)、そして部分的にはユニット テスト スイートに「ノイズ」を導入するためです。単体テスト ライブラリのコンテキストは、アプリケーション内のコードのみをテストすることです。

于 2010-06-17T21:14:37.297 に答える