很长一段时间php dev和rails newb我一直试图掌握tdd / bdd。有太多的工具和方法，这可能是一项非常艰巨的任务。经过大量阅读后，我得出的结论是，这将是我首选的测试方法：
作为一个完整的BDD新手，这可能会偏离基础，所以随时提供有关此测试'堆栈'的建议。
我真正想要的是使用这些工具的开源项目，我可以寻找灵感。
教程也会受到赞赏，但我认为看到一个真实的世界项目实现所有这些想法将非常有帮助。
答案 0 :(得分：10)
每个人似乎都有自己的测试方法，适合他们。我的背景就像你的一样 - 长期的PHP开发人员不使用测试（但在开发过程中进行了大量的手动白盒测试）。我最近开始编写我的第一个生产级别，即用于Rails的应用程序。这是我在前三个月后的想法。
我也发现Cucumber对我来说太复杂了。我终于意识到自己离实际的测试框架太远了，所以我很长时间都在努力。一旦我下降到纯RSpec，事情变得更加清晰。也就是说，现在我已经用强大的测试套件编写了我的第一个应用程序，我想我可能会将Cucumber放入我的下一个Rails应用程序配方中，并且在使用RSpec进行单元测试的同时使用它进行集成测试会感觉更舒服。
一旦我终于理解了这个过程，我就对RSpec产生了一种不健康的迷恋。运行这些测试并看到所有绿色真的很漂亮。实际上，看到红色是令人满意的，因为它告诉我接下来要做什么。
我正在使用默认的Webrat进行集成测试。我没有遇到任何Webrat无法解决的事情，但我没有给Capybara一个尝试，所以也许我只是不知道我有多糟糕。
我开始编写我的测试，跟随Rails教程书，其中作者说：“因为我不偏袒视图或帮助者的单独测试，我发现它是脆弱的或多余的，我们的第一步是删除它们。“ （第93页，第2段）在编写了一堆辅助方法之后，我决定回去为所有这些方法编写单独的帮助程序测试。我仍然将我的视图测试滚动到我的控制器测试中，但我可以看到在我的下一个项目中将它们分开。 FWIW，我认为你应该在某种程度上为所有事情编写测试，即使你只是依靠你的控制器测试来运用你的观点，和/或你的视图测试来练习你的帮助方法。
我正在使用Factory Girl这个项目，我发现它非常有用且易于使用。我没有尝试过机械师，但似乎同样受欢迎。我要提到的一件事是，当我第一次开始编写工厂时，我还使用FFaker gem为我创建的每个工厂对象生成随机内容。这开始看起来很不错，因为变量内容有时会让我找到我在开发中遗漏的东西（虽然现在想不到一个很好的例子），但这也意味着我不得不担心截断所有的返回FFaker数据以适应模型中的长度约束。从长远来看，这被证明是太笨重了，所以我删除了所有代码，并为我的所有工厂使用静态字符串，并且仅用于必需的字段。然后，当我想练习一个特定的领域时，我会按照我的实际规格进行操作。 IMO，你的工厂应该只包含足够的数据来创建一个有效的对象，而不是更多。
至于嘲讽，我只找到了一些我需要嘲笑的地方，但也许我对Rspec来说太新了，不知道我做错了。
最后，至于具体示例，只需查看GitHub上的示例Rails应用程序或包含测试的开源Rails项目。或者像我一样遵循Rails教程书。无论你决定做什么，尽量靠近金属，然后尝试不同的宝石/插件/等，如果你不喜欢结果，总是确保你可以退出你的更改。我发现尝试从一个完整的配方开始（即吊带，蓝光特殊等）太过于无法应对。通过从原始的Rails应用程序开始，我能够尝试不同的解决方案（回形针与载波，类型与rails_admin，清除与设计等），以查看哪些适合我的个人喜好。很明显，Rails应用程序没有一个完美的配方，每个人的首选配方只是一个意见。