单元测试背后的“意图” - 我应该瞄准什么？

Question

我今天围绕一个方法编写了一系列测试，该方法接受一个输入值并根据值是否通过某些（内部）验证测试返回不同的数据数组，即

[TestMethod] 
public void IsValidForValueFour()
{
    var result = myComponent.Validator(4);
    Assert.IsTrue(result[0], "Blah");
}

Validator()方法基本上在myComponent中私下存储的（硬编码）表中进行查找。

这感觉错了。我正在有效地测试私有查找表中的值。我应该关心传入和传出的值吗？我应该测试输出数组的长度而不是其内容吗？或者在给定一些输入值的情况下测试特定响应是否正确？

简而言之， intent 应该在这样的单元测试背后做什么？

Answer 1

这很有价值，因为您现在知道该功能正在返回它应该的功能。

将来，如果您更改了实现，只要测试全部通过，您就可以确保它仍然能够完成它应该做的事情。

---

至于你应该测试这些东西吗？由您决定要进行多少测试以及您认为从这些测试中获得的价值。

Answer 2

单元测试应该测试一小段代码，比如一个对象甚至一个方法，并且应该寻找方法/类可能会破坏的方法。恕我直言，一个永不休息的单元测试也可能不存在。 ;）

Answer 3

如果你的方法的合同是它返回"Blah"输入4，那么是的，你应该测试它！

Answer 4

MyComponent.Validator(4)的合同是它返回一个第一个元素为true的数组，然后这个测试很有用。但是，它实际上取决于该方法背后的逻辑有多复杂。我遵循的规则之一是，通过编写简短的方法，您可以跳过大量的测试：如果某些事情如此简单，可以通过视觉验证，通常不值得测试。

如果Validator()接受200个有效整数并从内部数组中为每个整数返回一个唯一的结果，我就不会费心去编写200个测试。我会为端点值编写测试并继续。

Answer 5

你应该通过传入许多有效数据，甚至更多无效数据来测试它，以确保它的工作方式与预期相符。这就是重点。你的方法必须做它应该做的事情，否则它需要重做。这样，此信息的使用者（您或可能是其他开发人员）可以使用该数据，而无需担心方法的内部实现。

事实上，如果你有一段评论包含你的阅读小说中的文字（这是愚蠢的，我承认），但你的方法接受并返回它应该说的内容，那么消费者永远不会知道或关心你是如何实现这种方法的。

Answer 6

如果从要求的角度来看很重要，你应该测试一下。如果重要的是值四必须返回“Blah”然后你有有效的测试 - 但我也肯定会将数字4提取到一个有意义的变量名称并将其传递给验证器。所以无论谁读过你的测试都会知道为什么你通过了四个值。 如果您正在测试某种算法，请尝试使用像Pex这样的工具为您生成输入。这也将确保您在SUD（被测系统）中的逻辑按预期运行。