我是否应该为方便重载重复测试？

对于我来说，为方法实现方便重载是非常常见的。这里是我可以做的事情的例子：我是否应该为方便重载重复测试？

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

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

我开始更加重视单元测试，以及测试这样的方法介绍了一些障碍，我不知道我相信我自己一个人接近。第一个也是最重要的问题是我是否应该为两种重载重复测试。例如，如果的值为空，则两种方法都应抛出ArgumentNullException;是否更正确地认识到可能是不同的逻辑并且写两个测试，或者更好地假设便利重载没有自己的逻辑？

我也有第二个问题。我的命名方案与Roy Osherove的相同：“MemberName_State_ExpectedResult”。如果我复制测试，那么我会在不引入一些古怪的命名约定的情况下碰撞名称。如果你复制测试，你如何处理这个问题？

来源

2009-10-12 OwenP

我经常不会像他们所说的核心方法那样测试方便的方法。例如你的ArgumentNullException情况。我不会测试两次。我的感觉是单元测试是白盒测试。我被允许知道实施。

当然，这可能意味着我将在以后重新构建并为便捷方法添加功能时被烧毁。但是我在TDD方面做得相当不错（从第一段可以看出，并不是一个狂热的玩家）。所以我想我很可能会为这个新功能写一个测试，然后覆盖它。

我并没有声称它或多或少是正确的。这正是我所做的。

来源

2009-10-12 21:45:56

如果您的所有构造函数调用完整定义的构造函数，我会打破测试分为
1）当前的单元测试，它必须是这样的
ConstructorShouldDoThisAndThat（）
2）重载专门的单元测试，指定什么默认情况下，过载用途，如 ConstructorWithNoEncodingShouldSetEncodingToDefaultEncoding（）

来源

2009-10-12 21:46:37 Mathias

“写两个测试或者是更好的假设，方便重载没有自己的逻辑是什么？”

恩......你的测试没有被“假设”所定义。它们由您正在测试的课程的设计来定义。

根据“假设”你不做任何事情。

如果方便的功能实际上是一个方便的功能，它必须做同样的事情，你必须写一个测试，证明这两种变异方法实际上做同样的事情。

如果“有可能是不同的逻辑”（1）这是不是一个真正的方便功能（2）你必须写一个测试，证明这两种变异方法实际上做正确的事（这可能与不同的逻辑相同，或者可能不同，我不能从这个问题中看出来。）

“MemberName_State_ExpectedResult，如果我重复测试，然后我有冲突的名称”

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

只有通过参数签名区分方法时，才能使用这个方法。所以，只要做出适合您所有便利功能的东西。

来源

2009-10-13 10:38:19

这两个帐户。有关验证便捷方法行为的简单方法，请参阅我对此问题的回答。 –

我认为答案很简单，那么你会想：你是否在意重载方法是否工作？如果你关心他们的工作，除非你测试他们，你怎么知道？

编写一个测试，比较重载函数的输出和重载函数的输出应该花费大约15秒的时间。做到这一点，继续前进。

来源

2009-10-13 10:43:51

我通常会做的是使'真正'的方法虚拟。这意味着我可以使用特定于测试的派生类（通常由动态模拟创建）来测试便捷方法，以验证它是否正确调用了“真实”方法。

如果“真实”方法和便捷方法之间的唯一区别是对特定参数使用默认值，则可以使用单个单元测试覆盖此值，然后继续。

我第二个S.Lott的关于命名约定的回答。

来源

2009-10-13 11:20:36

我是否应该为方便重载重复测试？

回答

相关问题