我应该重复测试以方便过载吗？

Question

对我来说,为方法做出方便的重载是很常见的.这是我可能会做的一个例子:

public void Encode(string value) {
    Encode(value, DefaultEncoding);
}

public void Encode(string value, Encoding encoding) { 
    // ... 
}

我开始更加关注单元测试,这样的测试方法引入了一些障碍,我不确定我是否相信自己单独进行测试.第一个也是最重要的问题是我是否应该重复两个重载的测试.例如,如果value为null ,则两个方法都应该抛出ArgumentNullException ; 是否更正确地认识到可能存在不同的逻辑并编写两个测试,或者更好地假设方便过载没有自己的逻辑？

我也遇到了次要问题.我的命名方案与Roy Osherove的相同:"MemberName_State_ExpectedResult".如果我复制测试,那么我会在没有引入一些古怪的命名约定的情况下发生冲突.如果复制测试,你如何处理？

Answer 1

"编写两个测试,或者更好地假设方便过载没有自己的逻辑？"

嗯....你的测试不是由"假设"定义的.它们是由您正在测试的类的设计定义的.

你不会根据"假设"做任何事情.

如果便捷函数实际上是一个便利函数,它必须做同样的事情,你必须编写一个测试,证明两个变量方法实际上做同样的事情.

如果" 可能存在不同的逻辑"(1)它实际上不是一个便利函数,(2)你必须编写一个测试来证明两种变体方法实际上都做了正确的事情(对于不同的逻辑可能是相同的,或者可能会有所不同,我无法从问题中分辨出来.)

" MemberName_State_ExpectedResult.如果我复制测试,那么我就会有冲突的名字"

避免愚蠢的一致性问题.如果你有不同签名的相同方法,那么这个命名约定不是很好,是吗？尽管存在问题,但忠实地坚持它是一种愚蠢的一致性.

当您拥有仅通过参数签名区分的方法时,您不能轻易使用此方法.所以只需制作一些适用于所有便利功能的东西.

Answer 2

我经常不会对便利方法进行与它们调用的核心方法相同的详细程度的测试。例如您的 ArgumentNullException 案例。我不会测试两次。我的感觉是单元测试是白盒测试。我被允许了解实施情况。

当然，这可能意味着当我稍后进行重构并向便捷方法添加功能时，我会被烧伤。但我在 TDD 方面做得相当不错（从第一段可以看出，我并不是一个十足的狂热分子）。因此，我认为我很可能会为该新功能编写一个测试，然后覆盖它。

我并不是说它或多或少是正确的。这就是我所做的。