Ruby / Rails测试实践

Question

尽管我仍然认为自己在ruby / rails领域有些菜鸟，但我有兴趣就如何测试Rails应用程序形成看法，包括如何使用技术和覆盖范围以及何时使用。 我目前的政策是顺应我正在进行的任何项目，但这在技术和覆盖水平上都产生了不一致的结果。 唯一的一致性在于测试优先开发风格。

用于控制器，模型和助手的Rspec，用于功能的黄瓜（以简化测试的第一开发），以及使用Test :: Unit进行回填以获取棘手的代码位？ 黄瓜所有功能？ 放弃测试：:单位？ 测试：：模型和助手的单元，黄瓜其他的？

请分享您的意见。

Answer 1

在测试应用程序时，最重要的事情之一就是编写可测试的代码，这比测试框架或方法更重要。

如果您使用测试驱动的方法进行开发，那么您自然会倾向于编写可测试的代码，但是您仍然需要专注于为自己提供适当的功能。 目标是拥有透明的应用程序。

需要关注的一些事情是：

• 使您的方法专注于特定功能，并在一种方法与另一种方法之间提供清晰的交接点。
• 对单元级对象的内部进行足够的自省，而不必暴露太多信息。
• 通过应用一致的术语和命名约定，创建以更紧密地映射到控制器和模型空间的方式构造的HTML文档。

我一直认为测试类似于魔术师的工作。 魔术师可以清楚地说明他们在做什么以及结果如何，但是过程本身并不一定要说明。 这就像您想知道结果但不应该关注实现细节的软件一样。

一个典型的魔术程序会向您显示所有相关的细节，例如表演者戴着帽子，帽子是空的，袖子没有东西，帽子结实，重量很小，然后他们就会拉扯一只兔子从帽子里出来。

就我个人而言，我倾向于更倾向于编写可靠的单元测试，并通过使控制器保持精简，而不太注重功能测试。 功能测试可能非常棘手，因为渲染页面时系统可能会处于大量不可能的状态。 由于您只能测试其中的一小部分，因此需要确定验证的优先级。

集成测试对于定义良好且缺陷成本很高的成熟应用程序非常有效，但与质量控制有严格要求的严格应用程序相比，集成测试可能要花费更多的时间。 不良的集成测试可能会给您带来错误的安全感，并可能实际上降低了应用程序质量。

如果您有专门的质量检查部门，可以专注于构建和维护全套回归测试，那么集成测试将是一件很棒的事情。 但是，对于一般的开发人员而言，这最终会造成巨大的重复劳动，并且可能严重影响生产力。 像许多事情一样，这是权衡的。