使用自动提款机
和无效的信用卡
插入卡后
并要求提取现金
>
那么就不应该提供现金了
并且应该保留卡
我想在项目的复杂场景下开始使用BDD，问题是我有一个问题：这种新的测试用例样式是否适用于更大的，真实的端到端场景，还是更适合于更简单的“原子”或单元测试样式的测试用例？
#1 楼
我不明白为什么它无法扩展。从概念上讲，它很简单（这自然使其对扩展性具有开放性。）但是，我会很疲倦-测试越复杂，效率就越低。如果您有测试，则担心过于复杂的“给定，何时，然后”（我几乎将其缩写为GWT，但意识到这会使人们感到困惑。提供更多反馈的组件。换句话说，是什么使它变得复杂？它有输入链，这是复杂的吗？如果是这样，那么您就有绝对的理由进行多次测试。复杂性的另一种常见介绍是，如果您输入类似“当___的结果是___时”，那应该是给定的，而不是时间。就我个人而言，我将归类为从何时到给出的归类为降低复杂性。#2 楼
尽管我没有使用SpecFlow的经验，但最近我开始使用StoryQ进行此类测试。尽管起初我对此非常厌倦，但是我发现它非常有用，包括在复杂场景中。现在，不仅代码变得更加井井有条，而且我发现编写更复杂的场景更加容易，因为这迫使我对其进行细分。#3 楼
首先，我认为您在用“认真”一词时就用了“愤怒”一词-但这纯粹是我的猜测。要回答您的问题，我会说“是”-换句话说，对于更复杂的情况，我会使用“给予”，“何时”，“然后”。#4 楼
您可以将“ Given / When / Then”用于具有任何共犯级别的方案，例如，非常特定的方案：
-end方案：
Scenario: Error when the password and confirm password do not match
Given I am on User Registration From
When I fill the Form fields as follow:
| Field | Value |
| Name | myusrname|
| Password| password123|
|Confirm Password | passnotmatch234|
And I click on the button “Save”
Then the error message should be “Password and Confirm password do not match”
在这种情况下，短语“然后注册应该成功”后面有以下检查：
Scenario: New user with unique name can be registered in the system
Given user with name “Uncle Bob” does not exists in the system
When I create a new user with name “Uncle Bob”
Then the registration should be successful
所有这些步骤都是隐式的，并隐藏在短语“然后注册应该成功”中，因为该方案的目的是检查具有唯一名称的用户是否可以在系统中注册。
评论
如果“然后”步骤失败，我如何获得明确的反馈来确定失败的原因是哪个基本断言（即1,2,3,4）？
– urig
18-09-15在6:45
评论
您能否澄清一下您的评论：“测试越复杂，效果越差？”单元测试和功能测试不应过于复杂；但是，客户（或端到端）方案/故事通常更复杂，并且涉及测试系统的多个部分。
– Bj Rollison
2012年6月12日下午13:57
测试的有效性只有在失败时才会发挥作用。该测试应该告诉您系统中发生了什么故障。测试越复杂，关于失败时实际破坏的信息就越少。
–corsiKa♦
2012年6月12日14:31
测试的有效性取决于测试提供的信息的价值（例如，重构后通过的单元测试为我提供了有价值的信息，重构后失败的单元测试也为我提供了有价值的信息）。随着测试变得越来越复杂，应该报告的信息也就越大。如果您设计复杂的测试并依靠简单的通过/失败预言，那么设计可能不是最佳的
– Bj Rollison
2012年6月12日20:43在