在单元测试设计中，很容易陷入实际上只是调用实现逻辑的陷阱。
例如，如果测试的int数组应该比另一个（2,4,6,8等）高两个，那么从方法中获取返回值并断言这种模式真的足够了是这样吗？
我错过了什么吗？通过以多种方式测试相同的期望，似乎需要使单个单元测试方法更加健壮。所以上面的期望可以通过检查正在发生的增加来确定，但下一个数字也可以被2整除。或者这只是多余的逻辑？
简而言之，单位测试应该以多种方式测试一个期望吗？例如，如果我想测试我的裤子适合我，我会/可以测量长度，把它放在我的腿旁边，看看比较等等。这是单元测试所需的那种逻辑吗？
由于
答案 0 :(得分：3)
您的单元测试应检查您的所有假设。无论您是在一次测试中还是多次测试中，都是个人偏好。
在上面的例子中，你有两个不同的假设：（1）每个值应该增加2.（2）所有值应该是偶数。
应该（-8，-6，-4，-2）通过/失败吗？
请记住，确保您的代码失败时应该同样重要，如果不是更重要的话，那么确保它在应该的时候通过。
答案 1 :(得分：1)
如果断言你的数组包含2,4,6,8 - 那么你的测试逻辑可能有缺陷，因为如果你刚刚返回一个带有这些元素的数组，你的测试就会通过，但是不会，例如，6,8 ，10,12。您需要测试计算是否正确。因此，在这种特殊情况下，您需要使用多个数组进行测试。
我发现确保测试失败，然后按照TDD的真正精神进行测试通过，有助于清除正确的测试...
答案 2 :(得分：1)
您正在测试的阵列必须以某种逻辑生成。是否更好地测试此逻辑以确保生成的数组始终满足您的要求？
答案 3 :(得分：1)
例如，如果测试一个数组 整数应该都高两个 比其他（2,4,6,8等），是 它真的足以获得回报 方法的价值并断言 这种模式是这样的吗？
也许您需要更多地思考如何使用该功能。是否会使用非常大的数字？如果是这样，您可能想尝试一些非常大的测试。它会与负数一起使用吗？
我错过了什么吗？看起来确实如此 像单个单元测试方法需要 通过测试使其更加强大 同样的期望在几个方面。所以 可以断言上述期望 通过检查增加两个是 发生但也是下一个数字 可以被2整除。或者这只是 冗余逻辑？冗余逻辑？
嗯......好的1,3,5,9会通过assertEachValueIncrementsByTwo测试，但它不会通过assertValuesDivisibleByTwo测试。他们可被2整除是否重要？如果是这样，那么你真的应该测试一下。如果没有，那么这是一个毫无意义的冗余测试。
您应该尝试为您的方法找到多个测试，但为了进行更多测试而进行的冗余测试对您没有帮助。在不真正需要的情况下添加assertValuesDivisibleByTwo测试只会让后来尝试修改代码的开发人员感到困惑。
如果您不能再考虑任何测试，请尝试编写一个随机输入函数，每次运行测试时都会生成100个随机测试数组。当您只检查一个或两个输入集时，您会惊讶地发现有多少错误在雷达下逃脱。
答案 4 :(得分：1)
我建议多次测试。如果您需要更改您希望尽可能少的测试更改的行为。这也使得更容易找到问题所在。如果你真的打击了实现并获得[1,3,4,5]你的一次测试将会失败，但是当你实际遇到两个不同的问题时，你只会遇到一次失败。
尝试命名您的测试。如果你不能用一个明确的方法名称来说明你正在测试的是什么，那就打破了测试。
testEntriesStepByTwo
testEntriesAllEven
另外不要忘记边缘情况。空列表可能会传递'每个条目比前一个条目多2个并且'所有条目都是偶数'测试，但它应该通过吗？