我目前正在阅读The Rspec Book的测试版：http://www.pragprog.com/titles/achbd/the-rspec-book
它将行为驱动的开发周期（红色，绿色，重构）描述为在开发过程中采取小步骤。这意味着一次添加一个功能。
我的问题是：
如果我要描述我的软件的单个功能（例如：黄瓜测试中成功的用户登录场景）以及我是否使用具有许多功能（场景）的模块化组件（例如Devise）。我怎么可能遵循行为驱动技术？一旦我的第一步通过，我必须对我的其他测试进行反向工程，以反映我正在使用的软件组件的功能，从而违反了BDD的原则！
编辑（为清晰起见）：
我的第一个场景是在实施Devise之后通过。但是现在我必须将我所有后续的端到端测试（我还没有写过）考虑在Devise的行为而不是我的利益相关者的要求。因此无法再应用BDD循环。我必须在测试中对Devise进行逆向工程，以使它们通过或不写测试。
答案 0 :(得分：1)
所以我可以更好地理解：你有一个现有的系统，它包括测试，但不包括登录功能。您决定添加登录信息：
Given a visitor is not logged in
When a visitor goes to the admin page
Then the visitor should see the login page
好的，那么你决定如何实现登录，因为这种情况失败了。对？因此，您选择Devise并且场景通过，但依赖于无安全系统的所有测试或规范现在都会失败。我还在赛道上吗？如果是这种情况，您会遇到一种情况，即您要在应用程序中添加一个非常普遍的功能，您需要触摸许多测试/规范才能使它们全部运行。您仍在测试，因为代码中断或测试无法识别新功能。无论如何，你知道需要做什么工作。
有用吗？
答案 1 :(得分：1)
BDD周期涉及创建场景，然后围绕这些场景进行对话，以发现任何缺失的场景，任何误解等等。
如果您使用像Cucumber这样的BDD工具，那么您可以捕获您讨论过的场景。
理想情况下，这些方案将采用高级步骤，重点关注系统功能及其为用户提供的价值。它们不会涉及登录或无法进行身份验证。
BDD并非真正关于测试。这是关于学习，让事情变得容易改变。如果您永远不会更改登录机制，那么手动验证身份验证就足够了。而是将注意力集中在使应用程序与所有其他应用程序不同的事物上。您的软件如何实际提供价值？它如何与其他系统，应用程序和用户通信？如何赚钱，或挽救生命，或有趣？
如果您可以回答这些问题并将步骤集中在那些问题上，那么即使使用Devise，您也会遇到失败的情况。您的方案看起来更像是：
Given I have registered an account
When I <do this differentiating thing>
Then I <achieve this differentiating outcome>
登录将是隐式的，并作为第一个Given的一部分调用为较低级别的步骤。