单元测试自动实现的属性是否有价值答案

【问题标题】：Is there value in unit testing auto implemented properties单元测试自动实现的属性是否有价值
【发布时间】：2010-06-17 21:07:57
【问题描述】：

这似乎异常繁重，但按照规则任何公开可用的东西都应该测试应该测试auto-implemented properties 吗？

客户类别

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);
    }
}

【问题讨论】：

标签： c# unit-testing tdd arrange-act-assert

【解决方案1】：

我通常认为任何不执行操作的代码都不值得测试。这通常意味着我不测试属性（无论是否自动实现），因为它们只是设置或返回一个值。

如果属性的 getter 或 setter 执行某种“工作”，例如可能根据其他字段/属性/其他的状态返回两个（或多个）值之一，这将改变。

如果你还没看过，我强烈推荐Roy Osherove's book on Unit Testing。它解决了各种“测试什么以及何时测试”类型的问题，包括这个问题。

【讨论】：

测试自动属性是在测试框架，而不是你的代码：没有代码逻辑需要验证。如果您最终在属性后面添加代码，您应该会看到测试覆盖率下降，这表明现在是时候测试该属性了。
它比看到测试覆盖率下降更简单......正如我在另一个回复中评论的那样，如果您更改代码以便它执行自动属性以外的其他操作，则应该驱动该更改通过测试，因此您将在那时测试功能上的更改。

【解决方案2】：

如果您从自动实现的属性切换到完全不同的属性会发生什么？测试似乎是多余的，因为您知道实现 - 您在编写测试时不应该考虑。

当然，这取决于您在短期内实际更改实施的可能性。

【讨论】：

如果发生这种情况，你会先写一个测试，对吧？因此，它将被测试。至少如果你做 TDD，那将是它的工作方式。我们都知道人们并不总是先编写测试。
+1 表示回归方面。今天它是一个汽车属性，但明天它可能需要修改以支持新的类功能等......

【解决方案3】：

这取决于您是在测试 API 是否符合预期的一组属性，还是如您所演示的那样，您只是在测试访问和设置属性。

在你给出的例子中，我会说不。

更新

符合预期的 API；如果您间接访问属性，例如在反射/动态环境中，并且您使用属性和方法访问调用来验证未知 API 是否符合预期。

【讨论】：

您能否详细说明“测试 API 是否符合预期的一组属性”的意思？

【解决方案4】：

测试设置和获取属性应该发生在测试对象的业务功能的上下文中。如果没有业务功能测试该属性，那么要么您不需要该属性，要么您需要更多测试。我建议您在添加需要它们的测试时添加属性，而不是在编写任何测试之前添加它们。

通过测试业务功能，从单元测试的角度来看，您将代码视为更多的黑盒。这使您可以在下面切换实现细节，而对测试的影响要小得多。由于重构是 TDD 周期的一个重要（并且经常被忽视）阶段，这意味着代码编辑要少得多。您可能还意识到（例如）该属性不应具有公共设置器，而应由执行验证和其他业务逻辑的方法分配。

【讨论】：

【解决方案5】：

单元测试应仅限于测试您在应用程序中实现的功能。

您不应测试您的应用程序所依赖的 API/SDK。部分原因是浪费时间（您的公司是否愿意为您测试 X-Third-Party 的 SDK/API 付费？），部分原因是它在您的单元测试套件中引入了“噪音”。单元测试库的上下文应该只测试应用程序中的代码。

【讨论】：

Customer 是我们拥有的一个类。
@ahsteele，是的，但您的测试可以说只测试 C# 编译器的行为。
@Yishai 同意，在重读答案时，我看到了 Warriorspostman 的意思。