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的值。

Fore read-only属性，我经常编写测试来验证该值是否与构造函数参数匹配。

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

Answer 2

查看其他SubSpec语法（[Specification]示例） - 在这种情况下，最后Assert中的每一个代表测试的单独执行。我最初将语法打折为lambda滥用，但现在我喜欢它已经使用了一段时间。

如何（策略）以BDD风格对单元测试属性（获取/设置）进行单元化？

2 个答案: