Question

有一门为测试选择好的输入的艺术。我们现在看到的这些是很随机的：

如何选择好的输入值呢？好的输入应该能彻底地测试代码。但是它们也应该很简单易读。

关键思想

基本原则是，你应当选择一组最简单的输入，它能完整地使用被测代码。

例如，假设我们刚刚写了：

尽管这个测试很简单，它没有测试SortAndFilterDocs()中“过滤掉负的分数”这一行为。如果在代码的这部分中有bug，这个输入不会触发它。

另一个极端是，假设我们这样写测试：

这些值复杂得没有必要。（并且甚至也没能完整地测试代码。）

简化输入值

那么我们能做些什么来改进这些输入值呢？

嗯，首先能可能会注意到的是非常“嚣张”的值-99 998.7。这个值的含义只是“任何负数”，所以简单的值就是-1。（如果-99998.7是想说明它是个“非常负的负数”，明确地用像-1e100这样的值会更好。）

关键思想

又简单又能完成工作的测试值更好。

测试中其他的值还不算太差，但既然我们都已经改了，那么把它们也简化成尽量简单的整数。并且，只要有一个负数来测试负数会被移除就可以了。下面是测试的新版本：

我们简化了测试的值，却并没有降低它的效果。

大型“破坏性”测试

对于大的、不切实际的输入进行测试当然是有价值的。例如，你可能会想包含一个这样的测试：

这样的大型输入在发现bug方面很有作用，比如缓冲区溢出或者其他出乎意料的情况。

但是这样的代码又大多看上去又吓人，对代码的压力测试来讲并无很好的效果。相反，用编程的方法来生成大型输入会更有效果，例如，生产100 000个值。

一个功能的多个测试

与其建立单个“完美”输入来完整地执行你的代码，不如写多个小测试，后者往往会更容易、更有效并且更有可读性。

每个测试都应把代码推往某一个方向，尝试找到某种bug。例如，下面有SortAndFilterDocs()的4个测试：

如果要非常地彻底，还可以写更多的测试。有分开的测试用例还可以使下一个负责代码相关工作的人更轻松。如果有人不小心引入了一个bug，测试的失败会指向那个具体的失败测试用例。