我正在尝试加入行为驱动的开发方法，但要使用它，我需要了解如何以这种方式思考。
我想在我现在开始的一个新的个人项目上对其进行测试（我将使用 RoR）
该项目将提供 API 来从外部应用程序收集数据，它将提供一个身份验证系统（设计）、几个模型来根据需要收集数据，以及一个购买订阅的支付系统，这将提供一些仅限高级功能的功能。
除了 DRY 之外，我应该执行哪些测试才能涵盖所有这些功能？
我想我应该同时使用 RSpec 和 Cucumber。对于 Devise，我将按照他们网站上的文档进行操作，但我不清楚我应该执行哪种测试来检查数据是否已正确收集并正确显示给用户以及用于该任务的工具。另外，如果您可以提供一个简单的示例，说明您将如何组织此类项目的测试和开发将有所帮助（我不是在询问真正的测试代码-因为我认为它确实取决于实现-，而是关于开发过程和您将执行的各种测试）。如果您需要更多详细信息来做出选择，请告诉我并随时发明它，因为它是出于教育目的。
我认为如果没有人插话，就不能提及 BDD，因为这完全是关于交流的。所以我会成为那个人：一切都与沟通有关！真正的价值在于与不同的利益相关者以可访问的方式探索功能，以确定系统需要透明地做什么。由于每个人都说同一种语言，因此交流目标要容易得多。在实现方面，开发人员知道他们在做什么，利益相关者知道他们得到了什么，不应该有太多的惊喜（除了你错过/错误捕获/可能还没有意识到的事情）。
所以，走出去，与你的利益相关者交谈，并弄清楚调试系统的人想要它做什么。如果这是一项单独的努力，您将需要戴上许多不同的帽子。
您的 BDD 测试将涵盖系统的行为 - 所需功能的单元。您仍然需要进行单元测试等 - 那里没有变化。
作为产品负责人，请考虑您希望系统做什么，而不是如何做。你可能不在乎事情是如何运作的，只要它们确实有效。如果您是开发人员，这可能是思维上的艰难转变。当我第一次开始研究 BDD 时，我确信在场景中经历 UI 旅程和技术细节等是有意义的。它没有。这些东西属于步骤定义。作为开发人员，您可以在那里定义所有内容。
至于保持干燥......准确地编写您的场景，以便捕获所需的行为。然后，您可以担心重构和确定步骤重用的机会。在某种程度上，使用正则表达式也会有所帮助。超级命令并拥有一整套可重复使用的步骤是很诱人的，但是当对单个步骤的更改波及所有场景时，您可能会意识到这一切都非常脆弱，而不仅仅是应该的场景影响。如果您对任何形式的网络自动化感兴趣，请查看网络自动化金字塔。
有用的资源（和很多例子）：
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 < 去团队声明！
我不确定这是否符合您的确切要求，但这就是我做 BDD 的方式（例如 webapp）：
假设您作为应用程序的用户坐在计算机前。写下实现其中一个用例所需执行的步骤，例如：
导航到系统的 url Login 选择您需要的功能 输入相关数据以执行功能 点击按钮启动功能 等待系统响应 确保屏幕上的数据与您期望的数据匹配。
如果这些步骤中的任何一个未能执行，或者数据不正确，则测试失败。
一旦你在测试文件中有这个，你就可以使用 Gherkin/Cucumber/Webdriver 来实现执行每个步骤所需的代码。每个方法都是可重复使用的，所以一旦你在一个地方实现了登录，它应该可以在你调用它的任何地方工作。
用黄瓜或 rspec 进行测试以进行设计试试这个
看到这个 - cucumber/rspec 或在 github