使用BDD Given/When/Then逻辑的测试命名与注释规范相关问题

测试方法命名规则 #

完全不需要使用完整的Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior格式，这类命名冗余度过高，过长的方法名反而会降低测试用例列表的可读性，提升信息筛选成本。
更推荐你提到的methodNameUnderTest_givenCondition_expectedBehavior简化格式，只要覆盖「被测方法、测试场景、预期结果」三个核心信息即可，多余的格式前缀可以直接省略。
比如测试登录接口密码错误的场景，命名为login_givenWrongPassword_returnAuthFail就足够清晰，完全没必要堆砌BDD关键词前缀。具体格式可以根据团队习惯调整，只要全团队规则统一、可读性达标即可。

Given/When/Then段落注释的必要性 #

是否加注释取决于测试用例的复杂度：

• 对于你示例中这类逻辑简短的单场景测试，注释属于锦上添花，既可以帮助不熟悉BDD的开发者快速理解代码结构，也不会带来冗余，完全可以保留。
• 对于多分支、多断言的复杂测试用例，强制添加// GIVEN、// WHEN、// THEN注释划分段落，能避免测试逻辑混乱，也方便后续维护时快速定位对应代码段，非常推荐添加。
  唯一需要避免的是硬套格式：如果测试逻辑本身没有明确的三段边界，强行加注释反而会误导后续维护人员。

你给出的示例代码的注释写法是行业通用的标准实现，清晰不突兀，可以直接纳入团队规范：

@Test
void findById() {

// GIVEN
Visit visit = new Visit();
given(visitRepository.findById(1L)).willReturn(Optional.of(visit));

// WHEN
Visit foundVisit = service.findById(1L);

// THEN
assertThat(foundVisit).isNotNull();
then(visitRepository).should().findById(anyLong());
}

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