RSpec vs Cucumber(RSpec 故事)[关闭]
Posted
技术标签:
【中文标题】RSpec vs Cucumber(RSpec 故事)[关闭]【英文标题】:RSpec vs Cucumber (RSpec stories) [closed] 【发布时间】:2010-09-28 11:04:40 【问题描述】:什么时候应该为 Rails 应用程序使用规范,什么时候应该使用 Cucumber(以前的 rspec-stories)?当然,我知道如何工作并积极使用规范。但是使用 Cucumber 仍然感觉很奇怪。我目前对此的看法是,当您为客户端实现应用程序并且还不了解整个系统应该如何工作时,使用 Cucumber 很方便。
但是如果我在做自己的项目呢?大多数时候,我知道系统的各个部分是如何交互的。我需要做的就是编写一堆单元测试。那么我需要 Cucumber 的可能情况是什么?
并且,作为相应的第二个问题:如果我写 Cucumber 故事,我是否必须写规范?这不是对同一件事进行双重测试吗?
【问题讨论】:
为什么我遇到的 every single [已结束] 问题被 Bill the Lizard 关闭为“不具建设性”,同时这个问题被多次投票!?!我错过了什么? 我完全同意。我仍然很困惑在哪里发布诸如“什么是 XXX 的最佳做法”之类的问题。 我同意,我一直在 SO 上遇到很好的问题,这些问题提供有见地、有用的答案,但由于某种原因而被关闭。 我在 2017 年发现了这个问题,因为它仍然具有相关性,而且仍然是一个很好的问题,有很好的答案。它也不会征求意见,因为所讨论的框架是由几乎相同的人为两个完全不同的问题设计的......但你需要一些专业知识才能知道这一点。 【参考方案1】:如果您还没有,不妨先看看 Dan North 的优秀文章,What's in a Story?。
Cucumber 故事有两个主要用途。首先,因为故事形式非常具体,它有助于集中产品所有者对他想要构建的功能的阐述。这是故事的“对话令牌”使用,无论我们是否在代码中实现故事都是有价值的。其次,当流程运行良好,我们在开始编写功能之前拥有完整的故事(更多的是我们为之奋斗的理想,而不是日常现实),你的验收标准就清楚了并且您确切地知道要建造什么以及建造多少。
在我们的 Rails 工作中,Cucumber 故事不能替代 rspec 单元测试。两者齐头并进。在实践中,单元测试倾向于推动模型和控制器的开发,而故事倾向于推动视图的开发(我们倾向于不为我们的视图编写 rspec)并从整体上提供对应用程序的良好测试用户视角。
如果您是单独工作,通信方面可能对您来说不是那么有趣,但您从 Cucumber 获得的集成测试可能会很有趣。如果您利用webrat,编写 Cucumber 可以快速轻松地完成许多基本功能。
【讨论】:
您将两个不同的问题混为一谈; 1) 进行集成和验收测试是否好,2) 黄瓜是编写这些测试的好工具。对于 1 - 是的,这显然是个好主意。对于 2,当您可以在 rspec 和 capybara 中编写非常清晰的集成和验收测试时,开发团队使用具有如此多间接性的语言编写测试很少有效率更高(或者 - 天堂禁止我们可能会研究 Ruby 的标准库 - test /unit 或 minitest,以及 capybara)。请参阅下面 Jack Kinsella 链接到的帖子。 完全同意你的看法,Abie!黄瓜整合至关重要!【参考方案2】:Cucumber 故事更多地描述了您的应用程序正在解决的整体问题,而不是单个代码位是否有效(即单元测试)。
正如 Abie 所描述的,它几乎是应用程序应满足的要求的列表,并且对于与您的客户沟通非常有帮助,并且可以直接测试。
【讨论】:
没错。 Cucumber 描述了您的应用程序的用法。例如。 “我点击这里,我希望得到这个或那个结果”。规格更多的是“模型”级别。就像,当我用这样那样的参数调用这些方法时,我希望它返回这个结果。【参考方案3】:把它想象成一个循环:
编写您的 Cucumber 功能,然后在开发该功能的部分时,编写规范以完成各个组件。继续完成规范,直到您编写了足够的功能以使该功能通过,然后再编写您的下一个功能。
【讨论】:
有一个很好的循环例子Outside-in BDD。【参考方案4】:但是如果我在做自己的项目呢?大多数时候,我知道系统的各个部分是如何交互的。我需要做的就是编写一堆单元测试。那么我需要 Cucumber 的可能情况是什么?
你仍然需要黄瓜。您需要它来记录您对系统工作的看法,并且您需要它来确保您在进行更改时没有破坏功能。
换句话说,您需要 Cucumber 故事的原因与您需要单元测试的原因相同——它们只是在更高的抽象级别上工作。
【讨论】:
我不会说 Cucumber 是必不可少的,但您当然应该进行某种集成测试,因为单元测试通常仅用于单独测试类。 对。在大多数情况下,Cucumber 是编写集成测试的最佳方式。【参考方案5】:如今,您可以将 rspec 与 Capybara 和 Selenium Webdriver 一起使用,而不必构建和维护所有 Cucumber 故事解析器。以下是我的建议:
-
写出你的故事
使用 RSpec,我将创建一个集成测试,例如:spec/integrations/socks_rspec.rb
然后我将创建一个集成测试,其中包含一个新的描述,并为每个场景阻止
然后,我将实现获得集成测试所需的最小功能,并在深入了解(进入控制器和模型等)的同时,对控制器和模型进行 TDD。
当您回来时,您的集成测试应该会通过,您可以继续向集成测试添加步骤
重复
但是,需要注意的一点是,控制器和集成测试有重叠,这可能是不必要的,因此您必须做出最佳判断,以免浪费时间。
此外,一旦你找到了自己的最佳状态,你会发现使用 BDD 进行开发是最令人愉快的,在此之前,如果你觉得自己做得不够完美,也不要过度思考,不要感到内疚。你会做得很好!
【讨论】:
【参考方案6】:我的看法是,在大多数情况下使用 Cucumber 是个坏主意,因为它的语法会给您带来生产力成本。我在Why Bother With Cucumber Tests?
中写了大量关于该主题的文章【讨论】:
我已经阅读了你的文章,作为黄瓜的粉丝,我必须说我同意你在文章中引用的许多观点。尽管如此,我仍然认为 cucumber 是一种将测试形式化并让外人易于阅读的好方法。 杰克 - 很棒的帖子。非常感谢你写它,你省去了我自己做的麻烦。 huug - 这可能是向“局外人”公开测试的好方法,但您向我展示一个想要阅读测试的非技术团队成员,我将向您展示一个团队浪费它的预算。此外,我还没有与项目中想要浪费时间阅读测试的非技术成员一起工作。我不知道,也许我很幸运...... 投反对票。我发现 用用户术语 描述用户功能对我作为开发人员很有用,无论用户是否阅读过我的 Cucumber 故事。这就是我在所有项目中使用 Cucumber 并鼓励其他人也这样做的原因。以上是关于RSpec vs Cucumber(RSpec 故事)[关闭]的主要内容,如果未能解决你的问题,请参考以下文章
如何使用rails cucumber,rspec,capybara在视图(dhtml)中测试动态部分?