RoR 野生中的 RSpec 和 Cucumber答案

【问题标题】：RSpec and Cucumber in the RoR wildRoR 野生中的 RSpec 和 Cucumber
【发布时间】：2016-04-30 15:32:27
【问题描述】：

我正在学习 RSpec 和 Cucumber，这样我就可以在工作中为我们的 Rails 网站编写测试。

在学习的时候，我用了一本书叫"The RSpec Book: BDD with RSpec, Cucumber and Friends"。在此期间，RSpec 用于粒度测试，Cucumber 用于整体可用性测试。

本书以一个简单的 CLI 游戏为例。

现在我正在进入网络环境，想知道在网络环境中进行测试的心态是什么。

我已经知道我将为我的模型和控制器编写规范测试。

我假设 Cucumber 的用处是全功能测试，它将使用控制器和模型来完成。

如果我错了，请纠正我，但假设有 User、Post 和 Likes 模型。

其中的每一个都有一个模型规格 + 无论多少控制器规格。

然后我会写一个单一的功能测试：

Feature: liking a post
  As a user of abc.com
  I want to like a post
  So that I can show my friends

我会在哪里以某人的身份登录，找到帖子并喜欢它？

任何有经验的人分享在 Rails 应用程序上使用这些工具进行测试的方法？

假设我必须实现上述情况，你会先充实特性测试，编写模型规范，然后编写控制器规范，然后编写代码吗？

【问题讨论】：

你在使用 Capybara 吗？设计？
是的，我正在使用 Devise 和 Capybara。

标签： ruby-on-rails testing rspec cucumber acceptance-testing

【解决方案1】：

[为了完整起见，重复其他人所说的一些内容：]

一种称为 BDD 的好方法（请参阅 bdd）由外而内地工作

通过验收测试（在 Ruby 世界中通常编写为 Cucumber 功能或 RSpec 功能规范）测试驱动功能
测试驱动细节与单元测试，以在必要时表达详细要求。

使用这种方法来测试 Rails 项目的一个特性，你首先要编写一个验收测试，然后实现它，这将产生路由、视图、控制器以及该功能所需的模型。由于您正在试驾，因此您还没有编写任何未经验收测试完全测试的代码，并且您还不需要任何控制器、模型等规范。然后您可能会重新开始另一个验收测试，或者您可能想使用较低级别的规范来测试一些详细的需求。

假设您的验收测试测试了用户的全名显示在页面上，并且您希望确保在用户未输入姓氏时它看起来正确。如果User#full_name 返回用户的全名，您可以只为该方法编写模型规范，而不是编写另一个验收测试。

根据我的经验，使用 BDD 编写的精心设计的 Rails 应用程序需要很少或不需要控制器规范，因为控制器应该尽可能多地委托给模型和其他类，因此完全通过验收测试进行测试。许多细节在模型规格中得到了最好的测试。

关于如何编写验收测试，我需要不同意其他人关于 Cucumber 的说法，或者至少给出警告：我已经看到 Cucumber 为大型生产应用程序生成了一个可读、可维护的验收测试套件，以及 RSpec功能规范会导致验收测试套件臃肿、无法维护，因此不要忽视 Cucumber 或其解决的需求：

不要被人类可读的验收测试仅适用于您的产品所有者或客户的想法所迷惑；它们对工程师来说绝对有价值，让您在适当的时候进行高层次的思考，而不是迷失在代码的噪音中。项目越大，您就越关心。
Cucumber 很好地将测试中步骤的接受级别描述与这些步骤的实现（CSS 选择器、ActiveRecord 查询等）分开，几乎自动使这些步骤可重用。使用 RSpec 功能规范，一切由您决定；准备好自己的系统，将细节提取到方法中，这些方法的名称清楚地表明每个步骤的用户级点是什么。（我指的不是页面对象；它们的详细程度低于我的意思，并且在 Cucumber 和 RSpec 功能规范中都很有用。）

【讨论】：

【解决方案2】：

黄瓜在这里的作用是作为验收规范。他们从用户的角度测试整个应用程序的行为。它们涵盖了从路由到控制器、模型和视图的整个堆栈。

在 BDD 中，您经常使用验收测试，而不仅仅是像在 TDD 中那样锦上添花，而是作为所谓的开发外部的驱动力。

在开发中中，您将创建一个失败的规范，在设置路由、控制器或任何基础之前详细说明用户故事。

将此与传统的 TDD 方法进行比较，在传统的 TDD 方法中，您首先将事物分解为最小的单元，以获得快速的红 - 黄 - 绿循环。然后你会开始将块堆叠在一起，测试逐渐覆盖越来越多的堆栈。

但这并不意味着验收规范是唯一有用的规范形式——它们的开销相当大，而且很难测试边缘情况。因此，仅使用 Cucumber 并不是一个非常有吸引力的解决方案。

【讨论】：

诚然，我从一开始就没有真正理解使用 cucumber 的意义——所有这些额外的抽象层只是为了假设您的客户实际阅读测试的错误前提。我只是使用 RSpec 功能规范。

【解决方案3】：

首先，这是比其他任何东西都更多的意见，但这里是。通常，使用 TDD，我会尝试从外部工作（外部开发）。换句话说，编写功能规范，然后是控制器规范（如果需要），然后是模型规范。这里的基本原理是您的功能测试是您的应用程序面向用户的方面。预先关注高级用户行为有助于减少时间浪费和构建您不需要的东西。此外，如果您从功能测试开始，您可以根据需要模拟/存根应用程序的较低级别，例如控制器中的模型交互，从而产生更快且隔离良好的测试。

最后，再一次，这更像是一种观点——我认为同时使用 Cucumber 和 RSpec 有点过头了。 RSpec 工作正常，更好地处理单元测试，并且比 Cucumber 更容易维护。每次我使用两者创建一个项目时，我最终都会放弃 Cucumber 并坚持使用 RSpec。

具体来说，为了测试用户登录，我建议同时使用 Devise 登录助手，这使得登录用户更快更容易https://github.com/plataformatec/devise#test-helpers。

【讨论】：