我是BDD的新手，但我发现它非常有趣，并希望使用BDD开发我的下一个项目。在谷歌搜索和观看截屏后，我仍然有很多关于BDD在现实生活中的问题。
1。声明性或势在必行的场景？
我看到的大多数给定的时间场景都是用UI（命令式）编写的。
Scenario: Login
Given I am on the Login-page
When I enter 'AUser' in the textbox 'UserName'
And I enter 'APassword' in the textbox 'Password'
And I click the 'Login' button
Then I should see the following text 'You are logged in'
我发现这些测试非常脆弱，并且没有说明点击按钮的商业价值。我认为它的噩梦要维持。为什么大多数示例都使用命令性场景？
Scenario: Login (declarative)
Given I am not logged in
When I log in using valid credentials
Then I should be logged in
如果您更喜欢声明式样式，您如何描述“主页”或“产品页面”等内容？
2。是否运用UI？
我看到的大多数步骤实现都使用WatiN，White或类似的东西从用户的角度来实现场景。启动浏览器，单击按钮。我认为它极其缓慢而脆弱。好吧，我可以使用类似Page对象的东西来减少测试。但那是另一项工作。特别是对于具有复杂UI的桌面应用程序。
如何在现实项目中实施场景 - 运行UI，或通过测试控制器/演示者？
第3。真的数据库与否？
当给定部分场景时，通常需要一些数据存在于系统中（例如，一些用于商店应用的产品）。您如何实现该部分 - 将数据添加到真实数据库（完整的端到端测试），或者向控制器提供存储库存根？
等待有经验的答案！
更新：在问题上添加了有用的链接。
答案 0 :(得分：12)
Decolitive是正确的方式，IMO。如果你在谈论.aspx文件名页面，你做错了。故事的目的是促进开发人员和非开发人员之间的沟通。非开发人员不关心products.aspx，他们关心产品列表。您的系统会执行非开发人员认为有价值的内容。这就是您要捕获的内容。
这些故事讲述了您需要实现的高级功能。它是你的系统必须做的。真正告诉你是否已经这样做的唯一方法是实际上运用UI。对我来说，BDD SpecFlow故事并没有取代单元测试，而是它们是集成测试。如果你打破这个局面，你就会破坏企业从软件中获得的价值。单元测试是用户不关心的实现细节，他们只是单独测试每个部分。这无法告诉你A和B是否一直在一起工作（理论上它应该在实践中有趣的[读取：意外]事情发生时你实际上有两个部分互相玩耍）。自动端到端测试也有助于您的QA。如果功能区域中断，您就会知道它，并且当您确定破坏集成测试的内容时，他们可以将时间花在应用程序的其他区域。
这是一个棘手的问题。我们做了一个混合方法。我们确实使用数据库（在测试系统作为一件事情而不是单个组件之后集成测试），而不是在我们需要时使用Deleporter用Moq替换我们的存储库时重置配置。似乎工作正常，但无论哪种方式肯定有利有弊。我想我们自己仍在很大程度上解决这个问题。
答案 1 :(得分：7)
修改：我刚才发现这篇文章正在描述the concept of limiting yourself to talking only about specific domains to avoid brittle scenarios。
他的主要观点是，您可以谈论的最小域数是问题域和解决方案域。如果你在谈论这两个领域之外的任何事情，那么你涉及太多的利益相关者，你引入了太多的噪音，并且你使你的场景变得脆弱。
他还提到绝对的“陈述性”或“命令式”模型是一个神话。他谈到了一个名为“分块”的认知模型，他说在你的抽象的任何层面上，你都可以“大块”或“大块化”。这意味着您可以更明确地（如何？）或更多元（什么或为什么？）。通过询问“我们在做什么？”，你从命令式模型中掏腰包？你说“我们将如何做到这一点？”所以我想我不会在声明与命令方面挂得太多 - 就这个问题而言，它不会让你到处都是。
通过确定哪个利益相关方是该术语所属域名的专家，可以找出每个术语属于哪个域的内容。一旦确定了所有域名，就可以选择相关的术语是在其中一个场景中最突出的域名，或完全删除不合适的语句。如果这还不够，您可以拆分，进一步指定或移动方案，以便它可以满足这些要求。
顺便说一下，他还使用了登录UI的方案，因此你得到了具体的指导：）
编辑前 :(其中一些仍然适用。“DB或无数据库”和“UI或无用户界面”问题无关）
1 - 陈述性或势在必行的场景？
尽可能声明，虽然命令式具有一定的价值（在项目生命周期的某些点）。
对于不熟悉信息理论和设计的测试人员和业务分析师来说，这是一种更容易思考的方法。在确定问题域和工作流程之前，在项目早期考虑也更容易。它对探索性思维很有用。
声明随着时间的推移不易变化。由于GUI是应用程序的一部分，因此非常有用，因此非常有价值。一旦确定了问题域和工作流，就会更容易思考，并且更关注关系概念。它是一种更稳定，更普遍适用的模型。
如果您使用通用和声明性模型编写测试用例，则可以使用完整应用程序GUI自动化，集成测试或单元测试的任意组合来实现它们。
您如何描述“主页”或“产品页面”等内容？
我不确定我会在基本级别的功能和要求。您可以创建描述实现细节的子功能和子需求，例如特定的UI工作流。如果您正在描述UI的一部分，那么您应该定义UI功能/要求。
2 - 是否运用UI？
两个
我认为它极其缓慢而脆弱
是的，确实如此。使用UI和完整数据库集成执行每个高级场景/需求，但不要使用端到端UI自动化执行每个代码路径，当然也不要使用边缘情况。如果你这样做，你会花更多的时间让它们正常工作，而且实际上测试你的应用程序的时间要少得多。
您可以构建应用程序，以便进行低成本集成测试，包括基于单件UI的测试。单元测试也很有价值。
但是你进行的集成测试越少，你就会错过越多的前额错误。编写单元测试可能更容易，而且它们肯定不那么脆弱，但根据定义，您将测试较少的应用程序。
3 - 真实数据库与否？
两个
必须在整个系统到位的情况下完成高级端到端集成测试。这包括一个真正的数据库，在不同服务器上运行每个系统的测试等等。
你得到的级别越低，我提倡的模拟对象越多。
答案 2 :(得分：3)
不是按名称提及页面，而是描述它所代表的内容，例如
Scenario: Customers logs in successfully
When I log in
Then I should see an overview of ACME's top selling products
您可以直接针对底层API或模型进行测试，但是执行此操作的次数越多，就越有可能无法捕获集成问题。一种方法是通过少量的全栈测试来平衡事物，而更大的数字仅在两层之间进行测试。