代码之家 › 专栏 › 技术社区 › ahsteele tungi52

单元测试自动实现属性中是否有值

arrange-act-assert tdd unit-testing c#

7

ahsteele tungi52 · 技术社区 · 15 年前

这似乎特别重,但按规则办事 应该测试任何公开可用的内容 应该 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);
    }
}

5 回复 | 直到 15 年前

1

7

Arne 15 年前

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

当然,这取决于您很快实际更改实现的可能性。

2

10

ckramer 15 年前

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

如果一个属性的getter或setter执行某种类型的“工作”,比如可能根据其他字段/属性/任何内容的状态返回两个(或多个)值中的一个,这将改变。

如果你没有看到,我强烈推荐 Roy Osherove's book on Unit Testing . 它解决了各种“测试内容和测试时间”类型的问题,包括这个问题。

3

1

John Weldon user3678248 15 年前

这取决于您测试的API是否符合预期的属性集,或者,正如您所演示的,您只是测试访问和设置属性。

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

更新

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

4

1

AbstractCode 15 年前

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

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

5

0

warriorpostman 15 年前

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

您不应该测试应用程序所依赖的API/SDK。部分原因是浪费时间(贵公司是否愿意为测试X第三方的SDK/API付费?)部分原因是它在单元测试套件中引入了“噪声”。单元测试库的上下文应该只测试应用程序中的代码。