BDD/Gherkin注册场景编写误区及实现疑问求助

先优化你的Gherkin场景 #

原场景的步骤过于口语化且拆分不合理，BDD场景要聚焦系统可观测的行为，而非用户主观意愿或模糊动作。优化后的场景应该是：

Scenario: Successful registration with valid credentials
    Given a user with valid registration details:
        | name   | surname | email          | cardId    |
        | Marcos | Perez   | marcos@gmail.com | 23432423 |
    And the user is not registered in the system
    When the user submits the registration request
    Then the system should successfully register the user
    And the user's details should be stored in the system

疑问1：如何处理“用户想要注册”这类非软件相关表述？ #

这类表述属于用户主观意图，无法被系统验证，在BDD场景中应该被替换为可验证的前置状态：

• 直接去掉“用户想要注册”这类描述，转而定义用户的核心前置条件：拥有有效的注册凭据（如上面场景中的表格参数），且未在系统中注册。
• 你原步骤实现里，“用户想要注册”的代码实际是在创建用户对象，这部分逻辑应该整合到“Given用户拥有有效注册信息”的步骤中，避免步骤与实现逻辑脱节。

疑问2：使用fakeDB作为测试替身的断言方式是否合理？ #

fakeDB是完全合理的测试替身（Test Double），用来替代真实数据库、隔离测试依赖，但你的断言方式可以优化：

1. 避免用hashCode断言：hashCode存在碰撞风险，且无法直观验证用户属性是否正确存储。
2. 直接验证核心属性：检查fakeDB中存储的用户对象，与预期的姓名、邮箱、证件号等核心属性完全一致。
3. 补充业务规则验证：比如验证注册后系统是否返回成功状态、是否生成用户ID（如果业务有要求）等业务相关结果。

优化后的步骤实现代码 #

// 用参数化步骤接收注册信息，提升场景复用性
@Dado("a user with valid registration details:")
public void givenAUserWithValidRegistrationDetails(List<User> userData) {
    // 从表格中提取用户信息
    User user = userData.get(0);
    this.expectedUser = new User(user.getName(), user.getSurname(), user.getEmail(), user.getCardId());
}

@Dado("the user is not registered in the system")
public void givenTheUserIsNotRegistered() {
    fakeDB.removeIfExists(expectedUser);
}

@Cuando("the user submits the registration request")
public void whenTheUserSubmitsRegistrationRequest() {
    // 整合原步骤中分散的逻辑，直接调用注册服务
    this.registrationResult = logUpService.logUp(
        expectedUser.getName(),
        expectedUser.getSurname(),
        expectedUser.getEmail(),
        expectedUser.getCardId(),
        fakeDB
    );
}

@Entonces("the system should successfully register the user")
public void thenTheSystemShouldSuccessfullyRegisterTheUser() {
    // 验证注册结果的业务状态
    assertTrue(registrationResult.isSuccess());
    assertNotNull(registrationResult.getUserId()); // 如果业务逻辑中生成用户ID
}

@Entonces("the user's details should be stored in the system")
public void thenTheUsersDetailsShouldBeStored() {
    User persistedUser = fakeDB.findByEmail(expectedUser.getEmail());
    assertNotNull(persistedUser);
    // 逐个验证核心属性，确保存储正确
    assertEquals(expectedUser.getName(), persistedUser.getName());
    assertEquals(expectedUser.getSurname(), persistedUser.getSurname());
    assertEquals(expectedUser.getEmail(), persistedUser.getEmail());
    assertEquals(expectedUser.getCardId(), persistedUser.getCardId());
}

额外建议 #

• 步骤复用：使用参数化步骤（如表格参数）可以让同一个步骤适配不同测试场景（比如不同用户信息），提升测试代码复用性。
• 场景聚焦：每个Scenario只验证一个核心行为，比如成功注册、邮箱已存在注册失败、证件号无效失败等，避免场景过于复杂。
• 自然语言一致性：Gherkin的语言要让业务人员也能理解，避免技术术语，同时保持和步骤实现的逻辑对应。

内容的提问来源于stack exchange，提问作者JosePepeDev