RSpec 和 RoR 野外的 Cucumber
RSpec and Cucumber in the RoR wild
我正在学习 RSpec 和 Cucumber，这样我就可以在工作中为我们的 Rails 网站编写测试。
学习的时候用到了一本叫"The RSpec Book: BDD with RSpec, Cucumber and Friends"的书。在此期间，RSpec 用于粒度测试，Cucumber 用于整体可用性测试。
本书以一个简单的CLI游戏为例。
现在我正在进入web环境，想知道在web环境下测试的心态是什么。
我已经知道我将为我的模型和控制器编写规范测试。
我假设 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
我在哪里可以以某人的身份登录，找到 post 并点赞？
有没有人愿意分享在 Rails 应用程序上使用这些工具进行测试的方法角度？
假设我必须实现上述情况，您可以先充实功能测试，编写模型规范，然后编写控制器规范，然后编写代码吗？
黄瓜在这里的作用是作为验收规范。他们从用户的角度测试整个应用程序的行为。它们涵盖了从路由到控制器、模型和视图的整个堆栈。
在 BDD 中，您经常使用验收测试，而不仅仅是像在 TDD 中那样在蛋糕上加糖霜，而是将其作为所谓的 外部开发 的驱动力。
在开发之外你会创建一个失败的规范，在设置路由、控制器或任何基础之前详细说明用户故事。
将此与传统的 TDD 方法进行比较，在传统的 TDD 方法中，您首先将事物分解为最小的单元以获得快速的红-黄-绿循环。然后您将开始通过逐渐覆盖越来越多堆栈的测试将块堆叠在一起。
然而，这并不意味着验收规范是唯一有用的规范形式——它们有相当大的开销，并且很难测试边缘情况。因此，仅使用 Cucumber 并不是一个非常有吸引力的解决方案。
首先，这是比其他任何事情都更多的意见，但这里是。通常，对于 TDD，我尝试从外向内（outside-in-development）工作。换句话说，编写功能规格，然后是控制器规格（如果需要），然后是模型规格。这里的基本原理是您的功能测试是应用程序面向用户的方面。预先关注高级用户行为有助于减少时间浪费和构建不需要的东西。此外，如果您从功能测试开始，您可以 mock/stub 较低级别的应用程序，例如控制器中的模型交互，如有必要，这会产生更快且隔离良好的测试。
最后，再说一次，这更像是一种观点——我认为同时使用 Cucumber 和 RSpec 是过大的杀伤力。 RSpec 工作正常，更好地处理单元测试，并且比 Cucumber 更容易维护。每次我使用两者创建一个项目时，我最终都会放弃 Cucumber 并坚持使用 RSpec。
具体来说，为了测试用户登录，我建议同时使用 Devise 登录助手，这样可以更快更轻松地登录用户 https://github.com/plataformatec/devise#test-helpers。
[为了完整起见，重复一些别人说的：]
一种称为 BDD（参见 bdd）的好方法由
由外而内地工作
- 通过验收测试来测试功能（在 Ruby 世界中通常写为 Cucumber 功能或 RSpec 功能规范）
- 测试驱动细节与单元测试以在必要时表达详细要求。
使用这种方法来试驾Rails项目的一个功能，你首先要写一个验收测试然后实现它，这将产生路由、视图)、控制器和功能所需的模型。由于您是试驾，您还没有编写任何未通过验收测试完全测试的代码，您也不需要任何控制器、模型等规范。然后您可能会重新开始另一个验收测试，或者您可能想使用较低级别的规范来测试一些详细的需求。
假设您的验收测试测试了用户的全名显示在页面上，并且您希望确保在用户未输入其姓氏时它看起来是正确的。如果 User#full_name returns 用户的全名，您可以只为该方法编写模型规范，而不是编写另一个验收测试。
根据我的经验，使用 BDD 编写的结构良好的 Rails 应用程序需要很少或不需要控制器规范，因为控制器应该尽可能多地委托给模型和其他 类，因此完全由验收测试。许多细节最好在模型规格中进行测试。
关于如何编写验收测试，我需要不同意其他人关于 Cucumber 的说法，或者至少给出一个警告：我已经看到 Cucumber 为大型生产应用程序生成了一个可读、可维护的验收测试套件，和 RSpec 功能规范导致了一个臃肿的、不可维护的验收测试套件，所以不要忽视 Cucumber 或它解决的需求：
不要被人类可读的验收测试仅适用于您的产品所有者或客户的想法所愚弄；它们对工程师来说绝对有价值，可以让您在适当的时候进行高层次的思考，而不是迷失在代码的喧嚣中。项目越大，越用心。
Cucumber 很好地将测试中步骤的验收级别描述与这些步骤的实现（CSS 选择器、ActiveRecord 查询等）区分开来，几乎自动使这些步骤可重用。使用 RSpec 功能规格，一切由您决定；准备好提出自己的系统，将细节提取到方法中，这些方法的名称清楚地表明每个步骤的用户级点是什么。 （我指的不是页面对象；它们的详细程度低于我的意思，并且在 Cucumber 和 RSpec 功能规范中都很有用。）
我正在学习 RSpec 和 Cucumber，这样我就可以在工作中为我们的 Rails 网站编写测试。
学习的时候用到了一本叫"The RSpec Book: BDD with RSpec, Cucumber and Friends"的书。在此期间，RSpec 用于粒度测试，Cucumber 用于整体可用性测试。
本书以一个简单的CLI游戏为例。
现在我正在进入web环境，想知道在web环境下测试的心态是什么。
我已经知道我将为我的模型和控制器编写规范测试。
我假设 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
我在哪里可以以某人的身份登录，找到 post 并点赞？
有没有人愿意分享在 Rails 应用程序上使用这些工具进行测试的方法角度？
假设我必须实现上述情况，您可以先充实功能测试，编写模型规范，然后编写控制器规范，然后编写代码吗？
黄瓜在这里的作用是作为验收规范。他们从用户的角度测试整个应用程序的行为。它们涵盖了从路由到控制器、模型和视图的整个堆栈。
在 BDD 中，您经常使用验收测试，而不仅仅是像在 TDD 中那样在蛋糕上加糖霜，而是将其作为所谓的 外部开发 的驱动力。
在开发之外你会创建一个失败的规范，在设置路由、控制器或任何基础之前详细说明用户故事。
将此与传统的 TDD 方法进行比较，在传统的 TDD 方法中，您首先将事物分解为最小的单元以获得快速的红-黄-绿循环。然后您将开始通过逐渐覆盖越来越多堆栈的测试将块堆叠在一起。
然而，这并不意味着验收规范是唯一有用的规范形式——它们有相当大的开销，并且很难测试边缘情况。因此，仅使用 Cucumber 并不是一个非常有吸引力的解决方案。
首先，这是比其他任何事情都更多的意见，但这里是。通常，对于 TDD，我尝试从外向内（outside-in-development）工作。换句话说，编写功能规格，然后是控制器规格（如果需要），然后是模型规格。这里的基本原理是您的功能测试是应用程序面向用户的方面。预先关注高级用户行为有助于减少时间浪费和构建不需要的东西。此外，如果您从功能测试开始，您可以 mock/stub 较低级别的应用程序，例如控制器中的模型交互，如有必要，这会产生更快且隔离良好的测试。
最后，再说一次，这更像是一种观点——我认为同时使用 Cucumber 和 RSpec 是过大的杀伤力。 RSpec 工作正常，更好地处理单元测试，并且比 Cucumber 更容易维护。每次我使用两者创建一个项目时，我最终都会放弃 Cucumber 并坚持使用 RSpec。
具体来说，为了测试用户登录，我建议同时使用 Devise 登录助手，这样可以更快更轻松地登录用户 https://github.com/plataformatec/devise#test-helpers。
[为了完整起见，重复一些别人说的：]
一种称为 BDD（参见 bdd）的好方法由
由外而内地工作- 通过验收测试来测试功能（在 Ruby 世界中通常写为 Cucumber 功能或 RSpec 功能规范）
- 测试驱动细节与单元测试以在必要时表达详细要求。
使用这种方法来试驾Rails项目的一个功能，你首先要写一个验收测试然后实现它，这将产生路由、视图)、控制器和功能所需的模型。由于您是试驾，您还没有编写任何未通过验收测试完全测试的代码，您也不需要任何控制器、模型等规范。然后您可能会重新开始另一个验收测试，或者您可能想使用较低级别的规范来测试一些详细的需求。
假设您的验收测试测试了用户的全名显示在页面上，并且您希望确保在用户未输入其姓氏时它看起来是正确的。如果 User#full_name returns 用户的全名，您可以只为该方法编写模型规范，而不是编写另一个验收测试。
根据我的经验，使用 BDD 编写的结构良好的 Rails 应用程序需要很少或不需要控制器规范，因为控制器应该尽可能多地委托给模型和其他 类，因此完全由验收测试。许多细节最好在模型规格中进行测试。
关于如何编写验收测试，我需要不同意其他人关于 Cucumber 的说法，或者至少给出一个警告：我已经看到 Cucumber 为大型生产应用程序生成了一个可读、可维护的验收测试套件，和 RSpec 功能规范导致了一个臃肿的、不可维护的验收测试套件，所以不要忽视 Cucumber 或它解决的需求：
不要被人类可读的验收测试仅适用于您的产品所有者或客户的想法所愚弄；它们对工程师来说绝对有价值，可以让您在适当的时候进行高层次的思考，而不是迷失在代码的喧嚣中。项目越大，越用心。
Cucumber 很好地将测试中步骤的验收级别描述与这些步骤的实现（CSS 选择器、ActiveRecord 查询等）区分开来，几乎自动使这些步骤可重用。使用 RSpec 功能规格，一切由您决定；准备好提出自己的系统，将细节提取到方法中，这些方法的名称清楚地表明每个步骤的用户级点是什么。 （我指的不是页面对象；它们的详细程度低于我的意思，并且在 Cucumber 和 RSpec 功能规范中都很有用。）