Junit 初学者关于BDD过程的几个问题

这些天我读了几篇关于BDD的文章，想知道它在说什么。现在我有了一个基本的了解，但仍然不清楚整个过程

以下是我认为在BDD过程中应该做的事情：

所有涉众（BA、客户、开发人员、QA）坐在一起讨论需求，并在故事卡上写下商定的功能。这里我以“用户注册”功能为例：

As a user,
I want to register on the system,
so that I can use its services

以

Given/When/Then

格式创建几个场景，以下是其中之一：

Scenario: user successfully register
    Given an register page
    And an un-registered user
    When the user fills username "Jeff" and password "123456"
    And click on "Register"
    Then the user can see a "Success" message
    And the user "Jeff" is created in the system

使用一些BDD测试框架实现此场景，例如：

一个接一个的步骤

但我很快发现自己陷入了困境：这个场景需要页面、模型，也许数据库，似乎有很多事情要做

我现在该怎么办？ 我现在该怎么办？我是否需要与所有利益相关者讨论此场景？对于

BA/Customer/QA

，我认为他们并不真正关心实现，与其他开发人员讨论是一个好主意吗

假设在我与其他开发人员讨论之后，我们同意将它分成几个小部分。我们可以像刚刚使用cucumber jvm那样使用

scenario/Given/When/Then

格式将这些小部分作为“scenario”吗，或者我们可以像在TDD中通常使用的那样使用JUnit吗

1. If choose "cucumber-jvm", it seems a little heavy for small part
2. If choose JUnit, we need to involve more than one testing framework in a project
3. Is it the best if there is a single testing framework to do both things (not sure if there is)

假设我选择选项

2

，将JUnit用于小任务

以下是我在做出这一决定后将要做的事情：

现在，我们创建新的小测试来驱动实现，比如在数据库中创建用户，就像我们在TDD中通常做的那样。（红色->绿色->重构）。我们不关心cucumber测试的

场景：用户成功注册了
（失败），现在就把它放在那里。对吧?

我们用JUnit开发了更多的小测试，使它们变成红色->绿色->重构。（不完全黄瓜测试总是失败）

在所有的小测试都通过之前，我们转向cumber测试

场景：用户成功注册
。完成它，并确保它最终变成绿色

现在开发另一个场景，如果简单的话，我们可以用cucumber实现它，否则我们将不得不拆分它并编写几个jUnit测试

肯定有很多误解，甚至是非常基本的误解。因为我发现除了“与所有利益相关者讨论”部分之外，我没有从BDD中获得多少价值

我的错在哪里？感谢您的建议

不要从登录开始；从与其他系统不同的东西开始。为什么有人登录？他们为什么要使用这项服务？硬编码用户，假装他们已登录，关注其价值

如果你关注用户界面的细节，你会将自己与用户界面紧密地联系在一起，这使得用户界面很难改变。相反，看看系统正在提供什么功能。无论如何，我不建议使用登录场景，但如果我使用了，我希望它看起来更像：

Given Jeff isn't registered with the site
When he registers with the username "Jeff" and password "123456"  
Then his account creation should be confirmed  
And he should be invited to log in for the first time.

在这里查看“声明式与命令式”以了解更多信息

如果你的UI真的在变化，手动尝试这个场景，直到UI稳定下来。那么自动化就更容易了。当您进入更稳定的场景时，最好先自动化（TDD风格）

你现在该怎么办？大多数人都不会为UI编写类级测试，所以在您启动控制器和演示器层之前，不要担心它。使用同一种语言的框架通常比较容易，但是两个不同的框架就可以了。Cucumber/RSpec、JBehave/JUnit、SpecFlow/NUnit是非常典型的组合。尽可能少地完成第一个场景的工作。它不会太多，因为你可以硬编码很多。第二个场景将开始引入更有趣的行为，然后您将开始看到出现类级测试

顺便说一句，BDD从类级别开始，因此您可以对类执行相同的操作；想一个你可能如何使用它的例子，如果你的框架还没有这样工作，那么在评论中写下“给定、何时、然后”，然后填补空白

是的，你的黄瓜场景将一直是红色的，直到它不是

理想情况下，您将同时进行最后一次单元测试和Cucumber场景，而不仅仅是编写一些额外的代码。看到它最终变成绿色，我感到非常满意

BDD的初衷是去掉“测试”这个词，因为它会让人们把TDD这样的东西看作是关于测试的。TDD的真正意义在于清洁设计；理解代码的职责和行为，就像场景帮助您理解系统的功能和行为一样。编写系统级场景和类级测试也是正常的

不过，你已经领先于那些在开始编写代码之前忘记讨论场景的人！与利益相关者的对话是最重要的部分。在这些对话中包括一名测试人员可能会带来价值。测试人员非常擅长发现其他人错过的场景

---

看起来，就流程的其余部分而言，您几乎走在了正确的轨道上。您可能会发现我的个人资料中的其他BDD答案对您也有帮助。祝贺你，祝你好运

我认为在学习BDD的技巧时，先注册/登录是一件非常好的事情。几乎每个人都知道你为什么要登录一个系统，每个人都知道系统必须知道你是谁才能这样做，所以你必须先注册

完成这个简单的任务可以让您专注于BDD的一个较小的子集。通过缩小您的关注范围，您可以提高质量，同时

Given Jeff isn't registered with the site
When he registers with the username "Jeff" and password "123456"  
Then his account creation should be confirmed  
And he should be invited to log in for the first time.

Feature: Registration
  A pre-requistite for signing in, see sign_in.feature

  Scenario: Register
    Given I am a new user
    When I register
    Then I should be registered

Feature: Sign in
  Dependant on registration ...
  I want to sign in so I can have personalised content and ...

  Scenario: Sign in
    Given I am registered 
    When I sign in
    Then I should be signed in

Scenario: Sign in with bad password
  Given I am registered
  When I sign in with a bad password
  Then I should not be signed in
  And I should be told ...