虽然我仍然认为自己在 ruby/rails 领域有点菜鸟，但我有兴趣就如何测试 rails 应用程序（使用哪些技术和覆盖级别以及何时使用）提出意见。我目前的政策是顺应我正在进行的任何项目的流程，但这在技术和覆盖范围方面产生了不一致的结果。唯一的一致性是测试优先的开发风格。
Rspec 用于控制器、模型和帮助程序，cucumber 用于功能（以简化测试的首次开发）并使用 Test::Unit 回填以处理棘手的代码？黄瓜的所有功能？放弃测试::单元？ Test::Unit 用于模型和助手，而 cucumber 用于其他一切？
请分享您的意见。
【问题讨论】：
标签： ruby-on-rails ruby testing rspec cucumber
在测试应用程序时，比您的测试框架或方法更重要的事情之一就是编写可测试的代码。
如果您使用测试驱动的方法进行开发，您自然会倾向于编写可测试的代码，但您仍然需要专注于为自己提供适当的工具。目标是拥有一个透明的应用程序。
需要关注的一些事情是：
我一直认为测试类似于魔术师所做的事情。魔术师说清楚他们在做什么，结果是什么，但过程本身并不一定解释。这就像你想知道结果但不应该关心实现细节的软件。
一个典型的魔术套路会向你展示所有相关的细节，比如表演者戴着一顶帽子，帽子是空的，他们袖子里什么都没有，帽子很结实，重量很轻，然后他们就会想办法把兔子从他们的帽子里拉出来。
就我个人而言，我倾向于更倾向于编写可靠的单元测试，并且通过保持控制器精简，较少强调功能测试。由于系统在呈现页面时可能处于的大量状态，因此功能测试可能非常棘手。由于您只能测试其中的一小部分，因此您需要确定验证的优先级。
集成测试适用于定义明确且缺陷成本非常高的成熟应用程序，但在其他情况下，与有纪律、严格的质量控制应用程序相比，创建它们可能需要更多的时间。糟糕的集成测试会给你一种错误的安全感，实际上可能会降低应用程序的质量。
如果您有一个专门的 QA 部门可以专注于构建和维护一整套回归测试，那么集成测试是一件很棒的事情。但是，对于普通开发人员来说，它最终会造成大量的重复工作，并且可能会严重拖累生产力。像许多事情一样，它是关于权衡的。
【讨论】：