你的单元测试目标是什么类型的执行率（每秒测试 # 个）？对于单个单元测试来说，多长时间太长了？
我很想知道人们是否有任何特定的阈值来确定他们的测试是否太慢，或者只是当长时间运行的测试套件的摩擦变得更好时？
最后，当您决定测试需要更快地运行时，您使用什么技术来加快测试速度？
注意：集成测试显然又是另一回事了。我们严格来说是需要尽可能频繁地运行的单元测试。
回应综述：感谢迄今为止的出色回应。大多数建议似乎是不要担心速度——专注于质量，如果它们太慢，就选择性地运行它们。具有特定数字的答案包括每次测试的目标是 <10ms，最多 0.5 和 1 秒，或者只是将整个通常运行的测试套件保持在 10 秒以下。
不确定当它们都有帮助时将其标记为“已接受的答案”是否正确:)
所有单元测试应在一秒钟内运行（即所有单元测试组合应在 1 秒内运行）。现在我确信这有实际限制，但我有一个项目有 1000 次测试，可以在笔记本电脑上快速运行。您真的需要这样的速度，这样您的开发人员就不会害怕重构模型的某些核心部分（即，让我在运行这些测试时去喝杯咖啡……10 分钟后他回来了）。
此要求还迫使您正确设计应用程序。这意味着您的域模型是纯粹的，并且包含对任何类型的持久性（文件 I/O、数据库等）的零引用。单元测试都是关于测试那些业务关系。
现在这并不意味着您忽略测试您的数据库或持久性。但是这些问题现在被隔离在可以使用位于单独项目中的集成测试单独测试的存储库后面。在编写域代码时不断运行单元测试，然后在签入时运行集成测试。
目标是每秒进行 100 次测试。到达那里的方法是遵循 Michael Feather 的单元测试规则。
在过去的CITCON讨论中提出的重要一点是，如果您的测试没有这么快，那么您很可能无法获得单元测试的设计优势。
如果我们在谈论严格的单元测试，我会更注重完整性而不是速度。如果运行时间开始引起摩擦，请将测试分成不同的项目/类等，并且只运行与您正在处理的内容相关的测试。让集成服务器在签入时运行所有测试。
我倾向于更多地关注测试的可读性而不是速度。但是，我仍然尝试使它们相当快。我认为如果它们以毫秒的数量级运行，你就可以了。如果他们每次测试运行第二个或更多......那么你可能正在做一些应该优化的事情。
缓慢的测试只会在系统成熟并导致构建花费数小时时才会成为问题，此时您更有可能遇到许多缓慢测试的问题，而不是您可以轻松优化的一两个测试。 . 因此，如果您看到许多测试每次运行数百毫秒（或更糟，每次运行几秒钟），您可能应该立即注意，而不是等到它达到数百个测试需要很长时间（此时它正在运行）真的很难解决问题）。
即便如此，它只会减少您的自动构建发出错误之间的时间......我认为，如果它是一个小时后（甚至几个小时后）也没关系。问题是在您签入之前运行它们，但这可以通过选择一小部分与您正在处理的工作相关的测试来运行来避免。如果您签入的代码会破坏您未运行的测试，请确保修复构建！
我们目前在大约 3.something 秒内进行了 270 次测试。可能有大约 8 个测试执行文件 IO。
这些是在每台工程师机器上成功构建我们的库后自动运行的。我们有更广泛（和耗时）的冒烟测试，每晚由构建机器完成，或者可以在工程师机器上手动启动。
如您所见，我们还没有解决测试太耗时的问题。对我来说 10 秒是它开始变得侵入性的点，当我们开始接近它时，我们会看看它。我们可能会将较低级别的库移动到夜间构建或仅由构建机器执行的配置中，这些库更健壮，因为它们不经常更改并且几乎没有依赖关系。
如果您发现运行一百个左右的测试花费的时间超过几秒钟，您可能需要检查您归类为单元测试的内容以及是否将其更好地视为冒烟测试。
您的里程显然会根据您的开发领域而变化很大。
数据点——Python回归测试
以下是我的笔记本电脑上为 Python 2.5.2 运行“make test”的数字：
我根据每个测试来判断我的单元测试，而不是每秒的测试次数。我的目标是 500 毫秒或更少。如果高于此，我将研究测试以找出为什么需要这么长时间。
当我认为测试变慢时，通常意味着它做得太多。因此，只需通过将测试拆分为更多测试来重构测试通常就可以解决问题。我注意到我的测试运行缓慢的其他时间是，当测试显示我的代码存在瓶颈时，则需要对代码进行重构。
对于单个单元测试来说，多长时间太长了？
我会说这取决于编译速度。通常在每次编译时执行测试。单元测试的目的不是放慢速度，而是带来一个信息“没有坏，继续”（或“有什么坏了，停止”）。
在这开始变得烦人之前，我不会担心测试执行速度。
危险是停止运行测试，因为它们太慢了。
最后，当您决定测试需要更快地运行时，您使用什么技术来加快测试速度？
首先要做的是设法找出为什么它们太慢，问题是在单元测试中还是在被测代码中？
我会尝试将测试套件分成几个逻辑部分，只运行 应该受到我在每次编译时更改的代码影响的部分。我会减少运行其他套件的频率，也许每天一次，或者当我怀疑我可能会破坏某些东西时，至少在集成.
一些框架提供基于启发式（例如上次修改时间）的特定单元测试的自动执行。对于 Ruby 和 Rails，AutoTest 提供了更快和响应更快的测试执行——当我保存 Rails 模型app/models/foo.rb时，相应的单元测试test/unit/foo_test.rb就会运行。
我不知道其他平台是否存在类似的东西，但这是有道理的。
关于单元测试的最重要的规则之一是它们应该运行得快。
对于单个单元测试来说，多长时间太长了？
开发人员应该能够在几秒钟内运行整套单元测试，绝对不是几分钟。无论如何，开发人员应该能够在更改代码后快速运行它们。如果花费的时间太长，他们将不会费心运行它们，并且您会失去测试的主要好处之一。
你的单元测试目标是什么类型的执行率（每秒测试 # 个）？
您应该瞄准每个测试以毫秒为单位运行，任何超过 1 秒的时间都可能测试太多。
我们目前有大约 800 个测试在 30 秒内运行，大约每秒 27 个测试。这包括启动运行它们所需的移动模拟器的时间。它们中的大多数都需要 0-5 毫秒（如果我没记错的话）。
我们有一两个大约需要 3 秒的时间，这可能是检查的候选对象，但重要的是整个测试套件不会花费太长时间以至于它会推迟开发人员运行它，并且不会显着减慢我们的持续集成构建。
我们还将可配置的超时限制设置为 5 秒——任何花费更长的时间都会失败。