RSpec与黄瓜(RSpec故事)

什么时候我应该使用Rails应用程序的规格和黄瓜(前rspec故事)？当然,我知道如何工作和积极使用规范.但使用黄瓜仍然感觉很奇怪.我目前对此的看法是,当您为客户端实现应用程序并且不了解整个系统应该如何工作时,使用Cucumber很方便.

但是,如果我正在做自己的项目呢？在大多数情况下,我知道系统的各个部分是如何相互作用的.我需要做的就是写一堆单元测试.那时我需要黄瓜的可能情况是什么？

并且,作为相应的第二个问题:如果我写黄瓜故事,我是否必须编写规范？难道不是同一件事的双重测试吗？

1> Abie..：

---

如果你还没有,你可能想看看Dan North的优秀文章,故事中有什么？作为一个起点.

我们有黄瓜故事的两个主要用途.首先,因为故事形式非常具体,它有助于集中产品所有者对他想要构建的功能的清晰度.这是故事的"对话令牌"使用,无论我们是否在代码中实现故事,这都是有价值的.其次,当流程运作良好以至于我们在开始编写功能之前有完整的故事(更多是我们努力的理想而不是日常现实),您的清晰度明确了您的验收标准,并且您确切地知道了什么以及如何很多建设.

在我们的Rails工作中,Cucumber故事并不能代替rspec单元测试.两者齐头并进.在实践中,单元测试倾向于推动模型和控制器的开发,并且故事倾向于推动视图的开发(我们倾向于不为我们的视图编写rspec)并且从整体上提供对应用程序的良好测试.用户的观点.

如果你是独自工作,那么沟通方面对你来说可能并不那么有趣,但是你从Cucumber获得的集成测试可能是.如果您充分利用webrat,那么编写Cucumber可以快速轻松地完成许多基本功能.

---

你把两个不同的问题混为一谈; 1)进行集成和验收测试是否合适,2)黄瓜是编写这些测试的好工具.对于1 - 是的,这显然是个好主意.对于2,当你可以在rspec和capybara中编写非常清晰的集成和验收测试时,开发团队很少有效地用这么多间接的语言编写测试(或者 - 天堂禁止我们调查Ruby的标准库 - 测试/ unit或minitest,以及水豚).请参阅Jack Kinsella链接到下面的帖子.

2> Josiah Kiehl..：

---

把它想象成一个循环:

编写您的Cucumber功能,然后在为该功能开发部件时,编写规范以完成各个组件.继续完成规范,直到您已经编写了足够的功能来传递该功能,然后编写下一个功能.

3> Jack Kinsell..：

---

我的看法是,在大多数情况下使用Cucumber是一个坏主意,因为它会影响你的语法生产成本.我在为什么打扰黄瓜测试的主题上写了很多篇幅？

---

huug - 这可能是向"局外人"公开测试的好方法,但是你向我展示了一个想要阅读测试的非技术团队成员,我将向你展示一个浪费预算的团队.此外,我还没有与一个想要浪费时间阅读测试的项目的非技术成员合作.我不知道,也许我很幸运...

4> Dave Glassbo..：

---

黄瓜故事更多地描述了您的应用程序正在解决的整体问题,而不是单个代码位的工作(即单元测试).

正如Abie所描述的那样,它几乎是应用程序应满足的要求列表,对于与客户的通信非常有用,并且可以直接测试.

---

究竟.Cucumber描述了您的应用程序的用法.例如"我点击这里,我希望得到这个或那个结果".规格更多的是"模型"级别.就像,当我用这样的参数调用那些方法时,我希望它能返回这个结果.

5> PeppyHeppy..：

---

现在你可以将rspec与Capybara和Selenium Webdriver一起使用,避免构建和维护所有的Cucumber故事解析器.这是我建议的:

写出你的故事

使用RSpec,我将创建一个集成测试ex:spec/integrations/socks_rspec.rb

然后我将创建一个集成测试,其中包含一个新的描述,并为每个场景阻止它

然后我将实现最小功能需要进行集成测试,同时深入了解(进入控制器和模型等)我会在控制器和模型上进行TDD.

当您回来时,您的集成测试应该通过,您可以继续添加集成测试的步骤

重复

然而,有一点需要注意的是,控制器和集成测试有重叠,可能没有必要,因此您必须使用最佳判断,这样您就不会浪费时间.

此外,一旦你发现你的凹槽,你会发现使用BDD进行开发是最愉快的,直到那时如果你不觉得你做得很完美并且不要过度思考就不要感到愧疚.你会做得很棒!