我发现无法在单元测试中使用控制语句非常乏味和限制，并试图了解边界的位置以及我是否误解了指南。我知道在测试代码中直接使用任何控制逻辑（循环，if，switch等）是不好的。在库中使用控制逻辑来分解测试代码中的通用逻辑（仅供测试代码使用）是不是很糟糕？例如，如果我有一个构建对象的方法，并且该对象有许多组件实例（就像一个订单有多个产品），我不应该采用一个变量来指示帮助程序代码应该为该对象创建多少个组件（因为获取变量将应用循环来构建对象图）？如果这确实是单元测试的不良做法，那么另一类测试是否可以接受？
答案 0 :(得分：2)
测试中的控制流程
我总是发现测试中最基本逻辑之外的任何东西都是个坏主意。测试应尽可能具有说服力。如果你说明结果是什么而不是如何实现结果，它有一些优点：
首先，测试代码通常要简单得多（注意：“简单”在这里并不总是意味着“terser”，它只是意味着推理和跟随的意图更简单。）
其次，它使得在测试逻辑下的系统变得更加困难。如果您正在测试系统，您可能会在生产代码中出现错误，测试代码中出现相应的错误以及......通过测试。两次失败和一种虚假的安全感。
测试库
如果您依赖的库中有常见的测试助手类型，那么只要您测试它们就可以拥有逻辑！示例：在NUnit 2.5添加数据之前在驱动测试中，我们构建了自己的数据驱动测试功能并使用了相当多的功能。数据驱动的测试代码本身进行了测试，以确保其正常运行。在我看来，你用来验证正确性的任何东西都必须比平常更严格地审查。你不希望建立在产生错误结果的东西之上，是吗？ ：）
此外，想想NUnit本身。看看它的代码。实际上，您使用和依赖的一切 - 从跑步者本身到细节 - 都经过了广泛的测试，以确保其正确性。我认为对你自己的测试库采用相同的做法是明智的。