单元测试的“意图” - 我应该以什么为目标？

Question

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

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

Validator()方法基本上在myComponent中存储的一个（硬编码）表中进行查找。这种做法感觉不太对。我实际上是在测试私有查找表中的值。我应该关心传入和传出的值吗？我应该测试输出数组的长度而不是其内容吗？还是说我应该根据某些输入值来测试特定的响应？简而言之，这样的单元测试应该具有什么意图？

- flesh

Answer 1

这非常有价值，因为现在你知道该函数返回了应该返回的内容。

将来，如果你改变实现方式，只要测试都通过，你就可以确信它仍然能够正常工作。

至于是否需要测试这些内容？这取决于你想要进行多少测试以及你认为从这些测试中获得的价值。

- Oded

Answer 2

一个单元测试应该测试一小段代码，比如一个对象或者一个方法，并且应该寻找方法/类可能出错的地方。在我看来，一个从不出错的单元测试与不存在没有什么区别。 ;)

- Peter Lawrey

Answer 3

如果你的方法的合约是在输入值为4时返回"Blah"，那么是的，你应该进行测试！

- Oliver Charlesworth

Answer 4

MyComponent.Validator(4) 的合约是它返回一个数组，其第一个元素为true，那么这个测试就有用了。然而，这真的取决于该方法背后的逻辑有多复杂。我遵循的一个规则是通过编写简短、简单的方法，可以跳过许多测试：如果某些东西如此简单，可以通过视觉验证，通常不值得测试。

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

- David Harkness

Answer 5

你应该通过传入许多有效数据和更多无效数据来测试它，以确保它像它应该做的那样工作。这就是整个重点。你的方法必须按照它应该做的那样去做，否则它需要重新设计。这样，信息的使用者（无论是你还是可能是另一个开发人员）可以使用该数据而不必担心你的方法的内部实现。

事实上，如果你有一段注释包含你正在阅读的小说的文本（我承认这很愚蠢），但是你的方法接受并返回它应该返回的内容，那么使用者将永远不会知道或关心你如何实现该方法。

- MAW74656

Answer 6

如果从需求角度来看，这个需要进行测试。如果值为四必须返回“Blah”，那么你就有一个有效的测试 - 但我也肯定会将数字4提取为有意义的变量名称，并将其传递给验证器。这样，读取你的测试的人就会知道你为什么传递了值4。

如果你正在测试某种算法，请尝试使用像Pex这样的工具为你生成输入。这也将确保你在被测系统中的逻辑表现正常。

- Spock