使用Visual Studio 2017 NUnit和Resharper测试运行程序，在大型c＃项目（5000+）测试中进行TDD时如何保持良好的单元测试速度。即使这些测试中的每一个仅花费5毫秒，也需要25秒，对于TDD周期来说，这还是很慢的。
我们的测试既不调用数据库也不调用外部Web服务。他们只测试业务逻辑。
我发现使用moq单独执行Mock.Setup（）大约需要1毫秒。由于每个测试可能会调用一些最小起订量设置，因此这是我们缓慢的单元测试的主要原因。
有什么办法可以加快单元测试的速度吗？有没有比moq更快的模拟库？还是另一个速度更快的测试跑步者？
答案 0 :(得分：6)
您的整体评价不对：所有单元测试的 overall 运行时仍处于非常合理的范围内！
在进行开发（也许使用TDD）时，您并不关心所有单元测试。您只关心与当前组件/包装/ ...有关的那些！
例如：在文件A中进行更改时，您可能想（手动）运行目录A所在的所有单元测试。进行另一个小的更改后，运行这些再次测试。
然后，稍后，当您认为：“我现在已经完成”时，然后调用所有单元测试，以确保您不会破坏建筑物另一端的东西重新布置那间房间里的家具。
因此，答案是：您很好，请放心。
我们有5000多个Java单元测试。在我们最快的构建服务器上，可能需要大约10分钟才能完成所有工作。但这还是可以的。后端构建仍然会在20分钟后返回，并告诉我们“损坏”或“一切正常”。为什么？因为构建服务器仅在我确定变更集已完成并将其推送到服务器时才启动。
如果这25秒是一个问题，则因为您经常运行 all 测试是因为您手动触发了它们。现在：花点精力研究巧妙的方法，以便在有效解决特定问题时仅运行相关测试。 （在带有JUnit的Java中，这很容易：我单击当前程序包，然后“在此处运行所有测试）
答案 1 :(得分：0)
考虑摆脱您进行的大多数测试。
虽然我在单元测试和TDD方面没有很多经验，但是我做的经验有限，这表明大多数单元测试都没有用。作为我的观点的一个例子，有经验的人支持我的观点，请考虑以下两篇文章：
我不确定该讨论是否连续（即谁是第一个提出该讨论的人），但是这里有几个人引用了上面的文章并同意了这个观点，也许还添加了一些自己的观点。 ：
请注意，论点根本不是关于测试，而是关于广泛的单元测试，而不是集成和系统级测试。