作为长期的 php 开发人员和 rails 新手，我一直试图掌握 tdd/bdd。那里有太多的工具和方法，这可能是一项非常艰巨的任务。经过大量阅读后，我得出结论，这将是我首选的测试方法：
作为一个完整的 BDD 新手，这可能有点离谱，所以请随时就这个测试“堆栈”提供建议。
我真正想要的是一个使用这些工具的开源项目，我可以从中寻找灵感。
教程也将受到赞赏，但我认为看到一个真实世界的项目实施所有这些想法会非常有帮助。
【问题讨论】：
标签： ruby-on-rails-3 rspec open-source capybara bdd
似乎每个人都有适合自己的测试方法。我的背景和你的一样——长期的 PHP 开发人员不使用任何测试（但在开发时进行了大量的手动白盒测试）。我最近开始编写我的第一个生产级、通过玩 Rails 获得报酬的应用程序。以下是我前三个月后的想法。
我也发现 Cucumber 对我来说太复杂了。在最终意识到我离实际测试框架太远之前，我挣扎了太久。一旦我下降到纯 RSpec 事情变得更加清晰。也就是说，既然我已经编写了我的第一个应用程序并带有一个强大的测试套件，我想我可能会将 Cucumber 放入我的下一个 Rails 应用程序配方中，并且在仍然使用 RSpec 进行单元测试的同时使用它进行集成测试会更舒服。
一旦我最终理解了这个过程，我就对 RSpec 产生了一种不健康的迷恋。运行这些测试并看到所有绿色真的很漂亮。实际上，看到红色甚至是令人满意的，因为它告诉我下一步该做什么。
我正在使用默认的 Webrat 进行集成测试。我没有遇到任何 Webrat 无法解决的问题，但我也没有尝试过 Capybara，所以也许我只是不知道自己有多糟糕。
我开始按照 Rails 教程书编写测试，其中作者说：“由于我不偏爱对视图或助手进行单独测试，我发现它们要么脆弱要么多余，我们的第一步是移除它们。” （第 93 页，第 2 段）在编写了一堆辅助方法之后，我决定回去为所有这些方法编写单独的辅助测试。我仍在将视图测试滚动到我的控制器测试中，但我可以在我的下一个项目中看到将它们分开。 FWIW，我认为您确实应该在某种程度上为所有内容编写测试，即使您只是依靠控制器测试来执行您的视图，和/或您的视图测试来执行您的辅助方法。
我在这个项目中使用 Factory Girl，我发现它非常有用且易于使用。我没有尝试过Machinist，但它似乎同样受欢迎。我要提到的一件事是，当我第一次开始编写我的工厂时，我还使用 Ffaker gem 为我创建的每个工厂对象生成随机内容。起初这看起来不错，因为可变内容有时会导致我找到我在开发中遗漏的东西（虽然目前想不出一个好的例子），但这也意味着我不得不担心截断所有的返回 Ffaker 数据以适应模型中的长度约束。从长远来看，这被证明太笨拙了，所以我删除了所有这些代码，并为我的所有工厂使用静态字符串，并且只用于必填字段。然后，当我想练习特定领域时，我会在我的实际规格中这样做。 IMO，你的工厂应该只包含足够的数据来创建一个有效的对象，而不是更多。
至于模拟，我只找到了几个需要模拟的地方，但也许我对 Rspec 太陌生了，不知道我做错了。
最后，至于具体示例，请在 GitHub 上查看包含测试的 Rails 应用程序或开源 Rails 项目。或者像我一样跟随 Rails 教程书。无论您决定做什么，从尽可能接近金属开始，然后尝试不同的宝石/插件/等，如果您决定不喜欢结果，请始终确保您可以取消更改。我发现尝试从一个完整的食谱开始（即吊带、蓝光特殊等）太难以承受了。通过从一个原始的 Rails 应用程序开始，我能够尝试不同的解决方案（回形针与carrierwave、typus 与 rails_admin、clearance 与 devise 等），以查看哪些解决方案适合我的个人喜好。很明显，Rails 应用程序没有完美的配方，每个人的首选配方只是一种意见。
【讨论】：