虽然我仍然认为自己是ruby/rails领域的一个新手，但我有兴趣就如何测试rails应用程序形成自己的看法——使用哪些技术和覆盖级别以及何时使用。我目前的政策是随我所从事的任何项目的发展而发展，但这在技术和覆盖水平上都产生了不一致的结果唯一的一致性是测试优先的开发风格。
控制器、模型和助手的rspec，功能人员的cucumber（以简化测试优先开发）和复杂代码的test：：unit回填？所有的工作人员都吃黄瓜放弃测试：：单元？测试：模型和助手的单元，其他的都是黄瓜？
请分享你的意见。
最佳答案
在测试应用程序时，最重要的事情之一，比您的测试框架或方法更重要，是编写可测试的代码。
如果您使用测试驱动的方法进行开发，您自然会倾向于编写可测试的代码，但是您仍然需要集中精力为自己提供适当的工具。目标是拥有一个透明的应用程序。
需要关注的是：
使您的方法集中于特定的函数，并在一个方法和另一个方法之间提供清晰的交接点。
为单元级对象的内部提供足够的自省，而不必暴露太多信息。
通过应用一致的术语和命名约定，创建结构更接近控制器和模型空间的HTML文档。
我一直认为测试和魔术师的工作很相似。一个魔术师清楚地告诉我们他们在做什么，结果是什么，但是这个过程本身并不一定能被解释清楚这就像你想知道结果的软件，但不应该关心实现细节。
一个典型的魔术动作向你展示了所有相关的细节，比如表演者戴着一顶帽子，帽子是空的，袖子上什么都没有，帽子很结实，重量很轻，然后他们会不知怎么地从帽子里拽出一只兔子。
就我个人而言，我更倾向于编写可靠的单元测试，并通过保持控制器的精简，减少对功能测试的重视。由于呈现页面时系统可能处于不可能的大量状态，因此功能测试很难正确进行。由于您只能测试其中的一小部分，因此需要优先考虑验证。
集成测试对于定义良好且缺陷成本很高的成熟应用程序很有效，但在其他情况下，它们可能需要比严格的质量控制应用程序花费更多的时间来创建一个糟糕的集成测试会给您一种错误的安全感，并可能实际上降低应用程序质量。
如果您有一个专门的QA部门，可以专注于构建和维护一整套回归测试，那么集成测试是一件很好的事情不过，对于一般的开发人员来说，这最终会造成巨大的重复工作，并严重拖累生产力。就像许多事情一样，它是关于权衡的。