我们正在公司与TeamCity进行持续集成，并且我们在每次提交(1分钟窗口)时运行单元测试。
最近，我们在讨论一组单元测试应该持续多长时间，但是越短越好。
然而，我想知道对于一批单元测试的长度的最佳实践是什么?
您可以在单元测试中构建优先级，并且只使用一个子集作为检入门(构建验证测试，或BVT)。更少地运行低优先级的测试(例如，每天构建一次，每次测试通过一次，或者每次产品发布一次)。然后对每个(或每个套件)设置单独的执行时间限制，以满足您的开发团队。
我的优先级是基于我们能够多快地修复由测试失败发出的错误信号。P0的意思是"必须修复，即使我们不得不推迟计划"，P3的意思是"可能永远不会修复"。
我工作过的一个团队说bvt的每个特性不超过2分钟，并且对较低优先级的测试没有时间限制。开发者必须运行大约5个测试套件，并且我们的签到量是合理的，等待10分钟的伙伴构建。但是我们的"单元测试"是大型的、特殊环境要求的集成测试，所以YMMV
应该运行单元测试，直到它们全部完成;不要根据运行时限制单元测试集。如果你有很多单元测试，而且它们需要很长时间才能运行，那就研究一下如何在更快的硬件上运行CI系统;购买更昂贵的硬件比不进行单元测试要便宜得多，单元测试可以在问题变成主要错误之前检测到问题。
"越短越好"
但实际上，这取决于你问的是什么。是否应该删除测试以缩短构建?可能不会。您是否可以限制在每次提交构建上运行的测试范围?也许是这样。您是否应该限制在每晚构建上运行的测试?可能不会。构建所需的确切时间取决于您的团队、您的流程以及您如何将CI集成到其中。
非常简单，使(单元)测试更快或并行化它们…单元测试应该可以工作……