使用现有软件组件的行为驱动开发

Question

我目前正在阅读Rspec Book的测试版：http://www.pragprog.com/titles/achbd/the-rspec-book

它将行为驱动的开发周期(红色、绿色、重构)描述为在开发过程中采取小步骤。这意味着一次添加一个功能。

我的问题是：

如果我要描述我的软件的单个功能(例如:在黄瓜测试中成功的用户登录场景)，如果我使用的是具有许多功能(场景)的模块化组件(例如Devise)。我怎么可能遵循行为驱动的技术呢？一旦我的第一步通过，我必须对我的其他测试进行反向工程，以反映我正在使用的软件组件的功能，这违反了BDD的原则！

编辑(为清楚起见)：

我的第一个场景是在实现Devise之后通过。但现在，我必须考虑所有后续的端到端测试(我还没有编写)围绕设计的行为，而不是我的股东的要求。因此，BDD周期不再适用。我必须在我的测试中进行反向工程设计，以使它们通过或不编写测试。

Answer 1

BDD循环包括创建场景，然后围绕这些场景进行对话，以发现更多缺失的场景、任何误解等。

如果您使用像Cucumber这样的BDD工具，那么您可以捕获您已经讨论过的场景。

理想情况下，场景将以高级步骤的形式出现，重点关注系统的功能及其为用户提供的价值。它们不会是关于登录或身份验证失败的。

BDD实际上不是关于测试的。它是关于学习，并让事情变得容易。如果您永远不会更改登录机制，那么手动验证身份验证就足够了。相反，专注于那些使你的应用程序与所有其他应用程序不同的东西。你的软件实际上是如何提供价值的？它如何与其他系统、应用程序和用户通信？如何赚钱，如何拯救生命，如何获得乐趣？

如果您能够回答这些问题并将步骤集中在这些问题上，那么即使使用Devise，您仍然会遇到失败的场景。您的场景将看起来更像：

Given I have registered an account
When I <do this differentiating thing>
Then I <achieve this differentiating outcome>

登录将是隐式的，并且作为第一个给定步骤的一部分被称为较低级别的步骤。

Answer 2

因此，我可以更好地理解:您有一个现有的系统，它包括测试，但不包括登录功能。您决定添加登录名：

Given a visitor is not logged in
When a visitor goes to the admin page
Then the visitor should see the login page

好的，然后你决定如何实现登录，因为这个场景失败了。对吗？因此，您选择了Devise，场景通过了，但是所有依赖于无安全性系统的测试或规范现在都失败了。我还在正轨上吗？如果是这样的话，您会遇到这样的情况:您正在添加一个在您的应用程序中非常普遍的功能，以至于您需要接触许多测试/规范才能让它们全部运行。您仍在首先测试，因为要么代码损坏，要么测试无法识别新特性。在任何情况下，您都知道需要在哪里完成工作。

有帮助吗？