Ruby/Rails测试实践

Question

虽然我仍然认为自己是ruby/rails领域的新手，但我有兴趣形成一个关于我想如何测试rails应用程序的观点-使用哪些技术和覆盖级别以及何时使用。我目前的政策是与我正在进行的任何项目的流程保持一致，但这在技术和覆盖级别上都产生了不一致的结果。唯一的一致性是测试优先的开发风格。

Rspec用于控制器、模型和帮助器，cucumber用于functionals (简化测试首次开发)，Test::Unit用于棘手的代码片段？所有的功能与黄瓜？放弃测试：：单元？测试：：用于模型和帮助器的单元，以及用于其他一切的黄瓜？

请分享你的观点。

Answer 1

当涉及到测试应用程序时，比您的测试框架或方法更重要的事情之一是编写可测试代码。

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

需要关注的一些事情包括：

通过应用一致的术语和命名约定，使您的方法专注于特定的功能，并在一个方法和another.

• Providing之间提供清晰的交接点。

通过应用一致的术语和命名约定，对单元级对象的内部进行充分的自省，而不会暴露太多的HTML文档，这些文档的结构与控制器和模型空间映射得更紧密。

我一直认为测试类似于魔术师做的事情。魔术师清楚地知道他们在做什么，以及结果是什么，但过程本身并不一定得到解释。这就像软件一样，你想知道结果，但不应该关心实现的细节。

一个典型的魔术动作向你展示了所有相关的细节，比如表演者戴着一顶帽子，帽子是空的，袖子里什么也没有，帽子很结实，重量很轻，然后他们就会从帽子里拉出一只兔子。

就我个人而言，我倾向于更多地倾向于编写可靠的单元测试，并通过保持控制器精简，减少对功能测试的重视。功能测试可能很难正确执行，因为在呈现页面时，系统可能会处于不可能的大量状态。由于您只能测试其中的一小部分，因此您需要确定验证的优先级。

集成测试适用于定义良好且缺陷成本非常高的成熟应用程序，但除此之外，它们可能需要比严格的、严格的质量控制应用程序多得多的时间来创建。糟糕的集成测试可能会给人一种错误的安全感，实际上可能会降低应用程序的质量。

如果您有一个专门的QA部门，可以专注于构建和维护全套回归测试，那么集成测试是一件很棒的事情。然而，对于普通开发人员来说，它最终造成了巨大的重复劳动，并可能严重拖累生产力。就像许多事情一样，它是关于权衡的。