我正在尝试加入行为驱动的开发方法，但要使用它，我需要了解如何以这种方式思考。
我想在我现在开始的新个人项目上测试它(我将使用 RoR)
该项目将提供 API 来从外部应用程序收集数据，它将提供一个身份验证系统(设计)、多个模型来根据需要收集数据，以及一个用于购买订阅的支付系统，这将提供一些高级功能。
我应该执行什么样的测试才能涵盖除 DRY 之外的所有这些功能？
我想我应该同时使用 RSpec 和 Cucumber。对于 Devise，我将遵循他们网站上的文档，但我不清楚我应该执行哪种测试来检查数据是否已正确收集并正确显示给用户，以及该任务使用哪些工具。此外，如果您能提供一个简单的示例，说明您将如何组织此类项目的测试和开发，这将有所帮助(我不是在问真正的测试代码——因为我认为它确实取决于实现——而是关于开发过程和您将执行的各种测试)。如果您需要更多详细信息来做出选择，请告诉我并随意发明它，因为它是用于教育目的。
最佳答案
我认为，如果没有人插话，就不能提及 BDD，因为这全都与沟通有关。所以我会成为那个人:一切都与沟通有关!真正的值(value)在于与不同的利益相关者以可访问的方式探索功能，以确定系统需要透明地做什么。每个人都说同一种语言，沟通目标就容易多了。在实现方面，开发人员知道他们在做什么，利益相关者知道他们得到了什么，不应该有太多惊喜(除了你错过/错误捕获/尚未意识到的事情，也许)。
所以，走出去，与您的利益相关者交谈，并弄清楚调试系统的人希望它做什么。如果这是一项单独的工作，您将需要身兼数职。
您的 BDD 测试将涵盖系统的行为 - 所需功能的单元。您仍然需要进行单元测试等 - 那里没有变化。
作为产品负责人，请考虑您希望系统做什么，而不是如何。你可能不关心事情是如何工作的，只要它们能工作就行。如果您是开发人员，这可能是思维上的艰难转变。当我第一次开始研究 BDD 时，我确信在场景中完成 UI 之旅和技术细节等是有意义的。它没有。这些东西属于步骤定义。作为开发人员，您可以在那里定义所有如何的东西。
至于保持干燥……准确地按照您的需要编写您的场景，以捕获所需的行为。然后您可以担心重构和确定步骤重用的机会。在某种程度上，正则表达式的使用在这里也会有所帮助。变得 super 命令式并拥有一整套可重复使用的步骤很诱人，但您可能会意识到，当对单个步骤的更改会波及您的所有场景，而不仅仅是它应该发生的场景时，这一切都非常脆弱影响。如果您对任何形式的网络自动化感兴趣，请查看网络自动化金字塔。
有用的资源(以及大量示例):
http://books.openlibra.com/pdf/cuke4ninja-2011-03-16.pdf <很棒的免费电子书——读起来也很有趣。
http://www.slideshare.net/lunivore/behavior-driven-development-11754474 < Liz 真的很了解她!
http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/
https://www.google.co.uk/search?q=declarative+vs+imperative+BDD
关于ruby-on-rails - 通过实际示例了解 BDD，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12620897/