【发布时间】：2017-07-28 02:09:00
【问题描述】：
我现在应该为我的函数执行的复杂算法编写一个单元测试。该函数在调用时采用两个强制参数。基于两个参数的组合，该函数确实返回了一些东西。
function ReturnDesiredParagraphStyle(currParagraphStyle, nextParagraphStyle)
{
// logic
}
现在的问题是，要测试输入的任何组合以及函数所需输出的正确性，我必须在单元测试中编写一个复杂的逻辑，因为有很多可能的输入（每个参数大约 50 个） .复杂的逻辑将是一个循环，目的是我不必在单元测试中手动输入每个输入组合。
我明白大部分时间写这个单元测试会提供一个安全层，但是它不是让单元测试的概念有点荒谬（因为单元测试中的逻辑会是这样的）复杂并且没有任何东西测试单元测试中的逻辑）？
【问题讨论】：
-
为了懒惰而不正确地编写测试而编写复杂的逻辑是错误的。您只需编写一次测试，因此请花时间正确地完成并完成它。
-
你为什么不写这个作为答案？问题是函数的输入组合太多，可能太多了，无法在单元测试中手动编写它们。
-
如果我的数学是正确的，那么大约有 2450 种输入组合。在单元测试中手动输入太多了。
-
如果您不打算正确地测试代码，那么就不要费心编写测试了。它们毫无价值，因为您可以 a) 错过输入组合，b) 在您的 复杂逻辑 中引入错误测试，以及 c) 在该 复杂的逻辑打破了所有的测试。如果你不打算正确地做到这一点，为什么要这样做呢？只需运行您的代码，同时祈祷它可以工作。
-
但是你不觉得2450个组合太多了吗？如果有 10000 种组合怎么办（只需多几个输入就可以轻松实现）。我认为这是编写单元测试的人应该考虑的一点。我认为在某些时候单元测试的价值会降低，或者如果单元测试中没有复杂的逻辑可以让您免于输入所有组合，那么单元测试就无法编写。
标签： unit-testing testing architecture theory software-design