ruby-on-rails – 用一个实际的例子来理解BDD
|
我正在尝试加入行为驱动的开发方法,但要使用它我需要了解如何以这种方式思考.
我想在我刚开始的一个新的个人项目上测试它(我将使用RoR) 该项目将提供API以从外部应用程序收集数据,它将提供一个身份验证系统(设计),几个模型来根据需要收集数据,以及一个支付系统来购买订阅,这将提供一些仅限高级功能. 我应该进行哪些测试才能涵盖所有这些功能但干燥？ 我以为我应该同时使用RSpec和Cucumber.对于Devise,我会按照他们网站上的文档进行操作,但我不清楚我应该执行哪种测试来检查数据是否已正确收集并正确显示给用户以及哪些工具用于该任务.另外,如果你能提供一个简单的例子,说明你将如何组织这种项目的测试和开发将有所帮助(我不是在询问真正的测试代码 – 因为我看到它真的取决于实现 – 但是关于开发过程和您将执行的各种测试).如果您需要更多细节可供选择,请让我知道并随意发明它,因为它是出于教育目的. 解决方法
我认为没有人会因为沟通的全部内容而提及BDD.所以我会成为那个人：这都是关于沟通的！真正的价值在于与不同的利益相关者以可访问的术语探索功能,以确定系统需要透明地完成的工作.每个人都说同一种语言,沟通目标要容易得多.当涉及到实施时,开发人员知道他们正在做什么,利益相关者知道他们得到了什么,不应该有太多的惊喜(除了你错过/捕获错误/未实现的事情,也许).
所以,走出去,与利益相关者交谈,找出调试系统的人想要做什么.如果这是一个单独的努力,你将需要戴上一些不同的帽子. 您的BDD测试将涵盖系统的行为 – 所需功能的单元.你仍然需要进行单元测试等 – 没有变化. 作为产品所有者,请考虑您希望系统做什么 – 而不是如何做.只要它们起作用,你可能不关心事情是如何运作的.如果您是开发人员,这可能是思维方式的艰难转变.当我第一次开始研究BDD时,我确信在场景中浏览UI旅程和技术细节等是有意义的.它没有.那些东西属于步骤定义.作为开发人员,您可以定义其中的所有内容. 至于保持DRY ……为了捕捉所需的行为,准确地编写你的场景.然后,您可以担心重构和识别步骤重用的机会.在某种程度上,使用正则表达式也会有所帮助.超级强制性并且拥有一整套可重复使用的步骤是很诱人的,但是你可能会意识到,当一个步骤的变化在你的所有场景中涟漪时,它们都非常脆弱,而不仅仅是它应该的那个场景.影响.如果您对任何形式的Web自动化感兴趣,请查看Web自动化金字塔. 有用的资源(和很多例子)： http://books.openlibra.com/pdf/cuke4ninja-2011-03-16.pdf<很棒的免费电子书 - 阅读也很有趣. http://www.slideshare.net/lunivore/behavior-driven-development-11754474<丽兹真的很了解她的东西！ http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/ https://www.google.co.uk/search?q=declarative+vs+imperative+BDD<去团队声明！ （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |