如何(策略)以BDD样式对测试属性(获取/设置)进行单元化? [英] How (strategy) to unit test properties (get/set) in BDD style?

问题描述

我有一个具有属性的(很多)类.有些包含逻辑，有些则没有.假设我要测试这些属性，该怎么做?

I have a class (of many) that have properties. Some have logic in them and some don't. Assuming I want to test these properties, how do I go about doing that?

最近，我对BDD样式对创建单元测试很感兴趣.

Recently, I've been interested in BDD style for creating unit tests.

请参见此处和此处.

因此，我将设置上下文-基本创建SUT并加载所需的任何内容. 然后，在每个观察值(测试方法)中，我将验证特定属性包含其应包含的内容.

So I'd do a setup of the context - basically create the SUT and load up whatever is needed. Then in each Observation (test method), I'd verify that a particular property contains what it should contain.

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

Here's my question. If the SUT has 20 properties, then do I create 20 Observations/Tests? Could be more if one of the properties contained more interesting logic I guess.

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

但是如果将单个简单观测值汇总在一起会更好吗?

But would it be better if aggregated the simple ones in a single observation?

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

或者如果我使用自定义属性(可以多次应用于一个方法)，该怎么办.这样我就可以做到，像这样:

Or what if I used a custom attribute (that can be applied multiple times to a method). So that I can possible do, something like:

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

推荐答案

通常，您应该在每个测试仅包含一个逻辑断言之后进行努力.优秀的 xUnit测试模式包含了很好的讨论关于这一点，但要点是，如果只有一个原因导致测试失败，则可以更轻松地了解发生违规的地方.不过，与BDD相比，回归测试可能更有意义.

In general you should strive after having only one logical assertion per test. The excellent book xUnit Test Patterns contains a good discussion about that, but the salient point is that it makes it easier to understand where a violation occurs if there's only one reason a test can fail. That's probably a bit more relevant for Regression Testing than BDD, though...

所有这些都意味着，尽管您可能会 认为验证所有属性是一个逻辑断言，您选择编写一个用于验证所有属性的测试的吸引力可能最弱.

All this implies that your option of writing a single test that verifies all properties is probably the least attractive, although you could argue that verifying all properties is a single logical assertion...

xDD(TDD，BDD等)的更主要的宗旨是测试应作为可执行规范.换句话说，当您查看测试时，不仅要要测试什么，还要要为什么原样保持预期，就应该立即显而易见.在您的示例中，尚不清楚为什么SUT.FirstName应该是"John"而不是"Jane".

A more central tenet of xDD (TDD, BDD, whatever) is that tests should act as Executable Specifications. In other words, it should be immediately apparent when you look at the test not only what is being tested, but also why the expected value is as it is. In your examples, it is not very clear why SUT.FirstName is expected to be "John" and not, say, "Jane".

如果可能的话，我会编写这些测试以使用推导值而不是硬编码的值.

If at all possible, I would write these tests to use Derived Values instead of hard-coded values.

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

For writable properties, I often write tests that simply verify that the getter returns the value assigned to the setter.

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

Fore read-only properties, I often write tests that verify that the value matches a constructor argument.

可以将此类测试封装到可重用的测试代码中，该代码封装了常见的测试习惯用法.我目前正在研究能做到这一点的库.

Such tests can be encapsulated into reusable test code that encapsulates common testing idioms. I'm currently working on a library that can do just that.

这篇关于如何(策略)以BDD样式对测试属性(获取/设置)进行单元化?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！