在单元测试设计中，很容易陷入实际调用实现逻辑的陷阱。设计一个强大的单元测试 - 以几种不同的方式测试相同的逻辑？
例如，如果测试一个整数应该比另一个（2,4,6,8等）高的两个整数的数组，它真的足以从该方法获得返回值，并断言这模式是这样吗？
我错过了什么吗？它看起来像是一个单一的单元测试方法需要通过几种方式测试相同的期望更健壮。所以上述期望可以通过检查两个增加的情况来确定，但下一个数字可以被2整除。或者这只是多余的逻辑？
因此总之，单元测试应该以几种方式测试一个期望？例如，如果我想测试我的裤子是否适合我，我会/可以测量其长度，将它放在我的腿旁边并查看比较等。这是单元测试所需的逻辑吗？
感谢
你的单元测试应该检查所有的假设。无论您是在1项测试中进行还是多项测试都是个人偏好。
在上面所述的例子中，您有两个不同的假设：（1）每个值应增加2.（2）所有值均应为偶数。
应该（-8，-6，-4，-2）通过还是失败？
请记住，确保您的代码失败时，它应该是同样重要的，如果不是更重要，那么确保它在应有的时候通过。
_你是否在1次测试中做到这一点，或者多次测试是个人偏好。我不同意。测试应尽可能小，尽可能简单，专门命名，并测试一件事。 – 2010-10-01 01:15:08
@托尼恩尼斯：我同意你的意见，但不打算开始一场神圣的战争:-) – Snekse 2010-10-01 14:46:21
嘿没有战争的意图;-) – 2010-10-01 17:26:05
如果断言你的数组包含2,4,6,8 - 那么你的测试逻辑可能是缺陷，因为你的测试会通过，如果你刚回到那些元素的数组，但与，比如6,8,10,12。您需要测试该计算是否正确。所以你需要用多个数组来测试它，在这种情况下。
我发现，要确保测试失败，则使测试通过，在TDD的真正精神，有助于冲洗出正确的测试是什么...
您正在测试的数组必须以某种逻辑生成。测试此逻辑以确保生成的数组始终满足您的要求会更好吗？
例如，如果测试的 整数数组，它都应该是比其他（2，4，6，8，等）两个较高 ，是 它确实足以让从返回 值该方法并断言 这种模式是这样吗？
也许你需要考虑更多关于如何使用函数。它会用于非常大的数字吗？如果是这样，你可能想要尝试一些非常大的数字。它会与负数一起使用吗？
我错过了什么吗？它看起来似乎是 就像一个单元测试方法需要 通过在几个方面测试相同的期望更健壮。所以 以上的期望可以断言 通过检查增加两个是 的情况发生，而且下一个数字是 整除2.或者这只是 冗余逻辑？冗余逻辑？
嗯......好吧1,3,5,9会通过assertEachValueIncrementsByTwo测试，但它不会通过assertValuesDivisibleByTwo测试。他们可以被2整除是否重要？如果是这样，那么你真的应该测试。如果没有，那么这是一个毫无意义的冗余测试。
您应该尝试为您的方法找到超过1个测试，但为了进行更多测试而进行的冗余测试不会对您有所帮助。如果真的不需要添加assertValuesDivisibleByTwo测试，只会让后来尝试修改代码的开发人员感到困惑。
如果您不能想到更多的测试，请尝试编写随机输入函数，每次运行测试时都会生成100个随机测试数组。当您只检查一个或两个输入设置时，您会惊讶地发现有多少错误在雷达下面逃脱。
我推荐多个测试。如果您需要改变行为，您希望尽可能少地进行测试。这也使得更容易找到问题所在。如果你真的打击了实现并得到[1,3,4,5]，那么你的一个测试将会失败，但是当实际上存在两个不同的问题时，你只会首先测试一个失败。
尝试命名您的测试。如果你不能用一个明确的方法名称说明你正在测试的是什么，那就分解测试。
testEntriesStepByTwo
testEntriesAllEven
另外不要忘记边缘情况。空列表可能会通过'每个条目比以前多2个'，'所有条目都是'测试，但是它应该如何？
因此，上述期望可以通过检查两个增加的情况来确定，但下一个数字也可以被2整除。或者这只是多余的逻辑吗？这是多余的。也可能是错误的 - 如果规范说“两个多”，那么5 7是正确的。但7不能被2整除（均匀，yadda） – 2010-10-01 01:10:18