代码之家 › 专栏 › 技术社区 › OwenP

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

overloading unit-testing

OwenP · 技术社区 · 15 年前

对我来说,对方法进行便利重载是很常见的。下面是一个我可能会做的事情的例子:

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

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

我开始更多地关注单元测试,像这样的测试方法会带来一些障碍,我不确定我是否相信自己能独自解决这些障碍。第一个也是最重要的问题是,我是否应该为这两个重载重复测试。例如,如果价值是空的;认识到这一点更正确吗能够使用不同的逻辑编写两个测试,还是假设便利重载没有自己的逻辑更好?

我还有第二个问题。我的命名方案和罗伊·奥舍罗夫的一样:“MemberName\u State\u ExpectedResult”。如果我重复测试,那么我就有了相互冲突的名称,而没有引入一些奇怪的命名约定。如果你重复测试,你该如何处理?

5 回复 | 直到 15 年前

S.Lott 15 年前

“编写两个测试,还是假设便利重载没有自己的逻辑更好?”

嗯。。。。你的测试不是由“假设”定义的。它们由您测试的类的设计来定义。

你不会做任何基于“假设”的事情。

如果便利函数实际上是一个便利函数,那么必须做同样的事必须编写一个测试,证明两种不同的方法 事实上 做同样的事。

如果“有” 能够 “不同的逻辑”(1)这不是一个真正方便的功能,(2)你必须编写一个测试,证明两种不同的方法 事实上 做正确的事情(逻辑上可能相同,也可能不同,我无法从问题中判断。)

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

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

当你的方法只能通过参数签名来区分时,你不能简单地使用它。所以,只要编一些适合你所有便利功能的东西就行了。

Mark Seemann 15 年前

我通常做的是用“真实”的方法 事实上的 。这意味着我可以使用特定于测试的派生类(通常由动态模拟创建)测试便利方法,以验证它是否正确调用了“real”方法。

如果“real”方法和便利方法之间的唯一区别是对特定参数使用默认值,那么您可以通过单个单元测试来覆盖这一点,然后继续。

我支持S·洛特关于命名惯例的回答。

Mike Two 15 年前

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

当然,这可能意味着,当我稍后去重构并向便利方法添加功能时,我会被烧死。但我很擅长做TDD(从第一段可以看出,我不是一个十足的狂热者)。所以我想我很可能会为这个新功能编写一个测试,然后介绍它。

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

Bryan Oakley 15 年前

我认为答案比你想的更简单:你在乎重载方法是否有效吗?如果你关心它们是否有效,除非你测试它们,否则你如何确定?

编写一个测试,将重载函数的输出与重载函数的输出进行比较,应该需要大约15秒的时间。去做吧,继续前进。

Mathias 15 年前

如果所有构造函数都调用完全指定的构造函数,我会将测试分解为
1) 您当前的单元测试,必须是
构造器应该这样做()
2) 专门针对重载的单元测试,指定重载使用的默认值,如无编码的构造函数应将编码设置为默认编码()