Rails 3.0是一只严肃的狗。我已经在Rails上开发了5年，而且启动时从未如此慢。特别是，测试需要永远在带有SSD的顶级MacBook上进行自举，因此迭代周期会受到严重影响。每次开始测试我都需要阅读一篇文章。这是疯狂而不是“敏捷”。我不妨编译。
这是我最终从Rails继续前进的主要动机 - 当我有机会的时候。
如果有人有解决方案，请提供。我知道很多人都会遇到这个问题。
我不使用rspec - 我知道有一个解决方案来帮助测试rspec。
我正在使用faster_require和rails-dev-boost，但没有产生重大影响。
我在ruby 1.9.2并且需要。在具有4Gb RAM和SSD的双核2.13 Ghz MacBook Air上进行一次非常简单的控制器测试需要26秒！为什么！？
答案 0 :(得分：18)
结帐spork。它本质上运行一个小型服务器，它运行引导，然后等待测试运行，允许你引导一次，然后从该状态多次测试。如果对配置进行某些类型的更改，您偶尔会重新启动它，但在大多数情况下，它可以让您进行非常快速的红绿重构迭代。
答案 1 :(得分：8)
引用Yehuda Katz：
C要求代码在1.9中做的事情会减慢速度。一个这样的例子是重新检查$ LOAD_PATH以确保它在所有需求上都被扩展。这是ruby-core应该解决的问题。如果没有redmine，我会在redmine上打开一张票。
我也遇到了这个问题，$ LOAD_PATH问题似乎是一个潜在的原因。让我们希望很快得到修复。
所以听起来像你只需要忍受这一点，希望它将在Ruby 1.9.3中修复。
答案 2 :(得分：7)
问题似乎是需求的缓慢，如果你做一些像
这样的最小分析CPUPROFILE=/tmp/my_app_profile RUBYOPT="-r`gem which perftools | tail -1`" ruby -I lib:test test/unit/user_test.rb
pprof.rb --text /tmp/my_app_profile
你可能会看到很多时间花在了需求上（另一种选择是在加载夹具中看到很多，但我想你已经知道这不是问题了。）
在我的盒子里（osx在macbook pro 2011 13上，带有核心i5和旋转硬盘），时间更多的是5秒，这仍然是很多但是更容忍，所以也许它是值得研究差异。
您在系统中安装了多少颗宝石？ 您是否尝试在没有bundler / rubygems的情况下运行测试/启动？
答案 3 :(得分：3)
支付不必编写“要求”声明是一种权衡。 Rails正在尝试做正确的事情，因此预先加载一切。基本上你有两个解决方案：
用我所说的全部，使用解决方案1）。让我的套件运行不到半秒钟（只有70次测试，但是等待Rails加载的次数很少）
答案 4 :(得分：3)
是的，它的速度非常缓慢。哦等等，在我的java时代，mvn install从未花费不到一分钟。使用mvn clean install时，它发疯了。快乐的日子，记住总会让我的精神振作起来。
+1 spork，正如@hammar建议的那样
与guard https://github.com/guard/guard-test结合使用以自动启动测试，并且您有一个杀手组合。让它在自己的窗口和/或屏幕上运行并看到你的工作效率上升：）
更新/补充回答：
优化提示：在application.rb中添加到autoload_paths的路径上放置to_s，避免它一遍又一遍地手动执行此操作。可能会刮掉几秒钟......
答案 5 :(得分：2)
正如@ user185374所说，你需要支付require的权衡。
我偶然发现了一个有趣的resource来加速Rails测试而不使用Rails ...这个例子是Rspec给出的，但你会有逻辑。
以下是作者的总结：
我无法告诉你跑步意味着什么 我的所有150多个规格在2秒内完成。 我认为这有点多余 工作，但值得努力！
我刚发现的另一个解决方案：Hydra并行测试：
http://logicalfriday.com/2011/05/18/faster-rails-tests-with-hydra/
答案 6 :(得分：2)
这是一个已知问题，尤其是在Ruby 1.9.2上。
好消息是a patch可以极大地加速Ruby启动（require）。
答案 7 :(得分：0)
好消息。升级到Ruby 1.9.3后，Rails在可容忍的时间内启动。
答案 8 :(得分：0)
查看zeus gem。
这应该会大大加快速度。