unit-testing - 如何(策略)以 BDD 风格对属性进行单元测试(获取/设置)？

Question

我有一个具有属性的(许多)类。有些有逻辑，有些则没有。假设我想测试这些属性，我该怎么做呢？

最近，我对用于创建单元测试的 BDD 风格很感兴趣。

参见 here和 here .

所以我会设置上下文 - 主要是创建 SUT 并加载所需的任何内容。然后在每个观察(测试方法)中，我将验证特定属性是否包含它应该包含的内容。

这是我的问题。如果 SUT 有 20 个属性，那么我是否创建 20 个观察/测试？如果其中一个属性包含更有趣的逻辑，我猜可能会更多。

[Observation]
public void should_load_FirstName()
{
    Assert.Equals<string>("John", SUT.FirstName);
}

[Observation]
public void should_load_LastName()
{
    Assert.Equals<string>("Doe", SUT.LastName);
}

[Observation]
public void should_load_FullName()
{
    Assert.Equals<string>("John Doe", SUT.FullName);
}

但是，如果在一次观察中汇总简单的会更好吗？

[Observation]
public void should_load_properties()
{
    Assert.Equals<string>("John", SUT.FirstName);
    Assert.Equals<string>("Doe", SUT.LastName);
    Assert.Equals<string>("John Doe", SUT.FullName);
}

或者如果我使用自定义属性(可以多次应用于一个方法)会怎样？这样我就可以做类似的事情:

[Observation(PropertyName="FirstName", PropertyValue="John")]
[Observation(PropertyName="LastName", PropertyValue="Doe")]
[Observation(PropertyName="FullName", PropertyValue="John Doe")]
public void should_load_properties()
{
}

Answer 1

一般来说，您应该努力争取每个测试只有一个逻辑断言。好书xUnit Test Patterns对此进行了很好的讨论，但重点是，如果只有一个测试失败的原因，它可以更容易地理解违规发生的位置。不过，与 BDD 相比，这可能与回归测试更相关……

所有这些都意味着您选择编写验证所有属性的单个测试可能是最没有吸引力的，尽管您可以争辩说验证所有属性是一个单一的逻辑断言...

xDD(TDD、BDD 等)的一个更核心的原则是测试应该充当可执行规范。换句话说，当您查看测试时，不仅正在测试什么，而且为什么期望值是原样，应该立即显而易见。在您的示例中，不清楚为什么 SUT.FirstName 应该是“John”而不是“Jane”。

如果可能的话，我会编写这些测试来使用 Derived Values而不是硬编码值。

对于可写属性，我经常编写测试来简单地验证 getter 返回分配给 setter 的值。

对于只读属性，我经常编写测试来验证该值是否与构造函数参数匹配。

此类测试可以封装到可重用的测试代码中，这些代码封装了常见的测试习惯用法。我目前正在研究 library that can do just that .