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

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

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

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

于 2010-06-17T21:14:12.730 回答
8

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

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

于 2010-06-17T21:13:16.173 回答
1

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

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

更新

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

于 2010-06-17T21:10:05.960 回答
1

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

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

于 2010-06-18T01:55:19.773 回答
0

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

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

于 2010-06-17T21:14:37.297 回答