如何在具有多个间接层的项目中使用单元测试

Question

我正在寻找一个相当现代的项目,重点是单元测试.按照古老的格言"面向对象编程中的每个问题都可以通过引入新的间接层来解决"这个项目是多层间接的.副作用是相当数量的代码如下所示:

public bool IsOverdraft)
{
    balanceProvider.IsOverdraft();
}

现在,由于单元测试的重点和维护高代码覆盖率,每一段代码都有针对它编写的单元测试.因此,这个小方法将有三个单元测试.那些会检查:

1. 如果balanceProvider.IsOverdraft()返回true,则IsOverdraft应返回true
2. 如果balanceProvider.IsOverdraft()返回false,则IsOverdraft应返回false
3. 如果balanceProvider抛出异常,则IsOverdraft应重新抛出相同的异常

更糟糕的是,使用的模拟框架(NMock2)接受了方法名称作为字符串文字,如下所示:

NMock2.Expect.Once.On(mockBalanceProvider)
    .Method("IsOverdraft")
    .Will(NMock2.Return.Value(false));

这显然使"红色,绿色,重构"规则变为"红色,绿色,重构,重新测试,重新测试,重新测试".使用不同的模拟框架(如Moq)将有助于重构,但它需要扫描所有现有的单元测试.

处理这种情况的理想方法是什么？

A)保持较小级别的层,以便不再发生这些转发呼叫.

B)不要测试那些转发方法,因为它们不包含业务逻辑.出于覆盖的目的,使用ExcludeFromCodeCoverage属性标记它们.

C)仅在调用适当的方法时进行测试,而不检查返回值,异常等.

D)把它吸干,并继续写那些测试;)

Answer 1

无论是B还是C.这就是这些一般要求的问题("每种方法都必须进行单元测试,每行代码都需要覆盖") - 有时,他们提供的好处不值得花费.如果这是你想出的东西,我建议重新考虑这种方法.在"我们必须有95%的代码覆盖率"可能会被吸引在纸面上,但在实践中迅速滋生就像你有一个问题.

此外,您正在测试的代码是我称之为琐碎的代码.对它进行3次测试很可能是矫枉过正.对于那一行代码,你必须保持40多个.除非您的软件是关键任务(这可能解释了高覆盖率要求),否则我会跳过这些测试.

关于这个主题的(IMHO)最实用的建议之一是肯特贝克不久前在这个网站上提供的,我在博客文章中对这些想法进行了一些扩展 - 你应该测试什么？