这是我们反复讨论的问题,人们的意见似乎相当不同。基本问题是,在进行TDD时,是否应该在循环重构步骤之后添加额外的单元测试。我不是在谈论下一个测试来开始下一个循环,而是指为了覆盖由于重构带来的任何更改而进行的测试。
这可能最好通过一个实际例子来解释。在TDD周期的绿色阶段之后,我们有以下代码:
这可能最好通过一个实际例子来解释。在TDD周期的绿色阶段之后,我们有以下代码:
public bool ShouldVerifyDomain
{
get
{
return this.Orders.SelectMany(x => x.Items).Any(x => x.Product.RequiresDomainVerification);
}
}
现在,我看到这个代码并想,嗯,那个linq语句可以更加简洁易读,不会违反Demeter法则,让我们重构一下。因此,我在订单(Order)
上创建了以下内容:
public bool HasItemsThatRequireDomainVerification
{
get
{
return this.Items.Any(x => x.Product.RequiresCascadeDomainVerification);
}
}
将ShouldVerifyDomain
进行了修改,修改后的内容如下:
public bool ShouldVerifyDomain
{
get
{
return this.Orders.Any(x => x.HasItemsThatRequireDomainVerification);
}
}
好的,看起来好多了,我对此感到满意。让我们继续进行我的测试清单中的下一个测试...但是...等等,现在我们正在通过另一个对象的属性测试HasItemsThatRequireDomainVerification
属性....这是真正的单元测试吗,还是我应该添加直接测试HasItemsThatRequireDomainVerification
的测试用例。
我的想法是什么?我认为这不会增加太多价值。我认为这会增加套件的维护负担,花费时间,而且在未来进行更改时并不能给我们更多的信心。
它可能会给我们带来什么?Order
的公共接口的“文档”。
你有什么想法?