初学者BDD过程中的几个问题

Question

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

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

import cucumber.api.java.en.Given;

public class Stepdefs {
    @Given("an register page")
    public void an_register_page throws Throwable {
        // ...
    }
    @Given("an un-registered user")
    public void an_register_page throws Throwable {
        // ...
    }
    // ...
}

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

我现在该怎么办？我是否需要与所有涉众讨论此方案？对于ba/customer/qa，我不认为他们真的关心实现，与其他开发人员讨论一下是不是一个好主意？

假设在我与其他一些开发人员讨论之后，我们同意将其拆分为几个小的部分。我们是否可以用scenario/gived/when/then格式使这些小部件成为“scenario”，就像我们刚才对cucumber-jvm所做的那样，或者我们是否可以像在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测试场景：用户成功注册（失败了），暂时把它留在那里。对吧？

Answer 1

>

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

如果您专注于UI细节，那么您就会非常强烈地将自己与UI绑定在一起，这使得UI很难更改。取而代之的是，看看系统正在交付什么功能。我并不推荐使用登录场景，但如果我使用了，我希望它看起来更像：

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.

在这里查阅“声明式vs.命令式”，了解更多关于这方面的内容。

BDD最初的目的是去掉“测试”这个词，因为它会让人们把TDD这样的东西看成是关于测试的。TDD实际上是关于干净的设计；理解代码的职责和行为，就像场景帮助您理解系统的功能和行为一样。同时编写系统级场景和类级测试应该是正常的。

但是，您已经领先于那些在开始编码之前忘记讨论场景的人了！与利益相关者的对话是最重要的部分。在这些对话中加入测试人员可能会有价值。测试人员非常擅长于发现其他人错过的场景。

看起来你在其他的过程中已经走上了正确的轨道。你可能会在我的个人资料中发现一些其他的BDD答案对你也有帮助。恭喜你，祝你好运！