我曾经创建场景,在场景名称中我解释什么是场景。例如:
场景:在上下文切换过程中,上下文不匹配并向用户显示要删除的事实列表,如果用户在列表中选择了事实,则应删除事实。
但问题是场景越来越复杂,场景名称越来越长。我应该继续写长名字还是你有更好的建议?
好吧,听起来你在重复自己。
下面的测试可能与您的意思不符。但假装它确实如此。
如果您的场景如下所示:
Given the current context is Green
And the following list of facts for delete are selected
| Fact | Checkboxstate |
| A | checked |
| B | |
| C | checked |
| D | |
When I perform a context switch to Orange
Then the following facts should be deleted
| Fact |
| A |
| C |
And the following facts should not be deleted
| Fact |
| B |
| D |
然后测试几乎不比您建议的场景标题复杂。(如果测试比这复杂得多,那可能是另一个问题)
而是尝试保持功能和场景标题简短而有意义:例如
Feature: Context Switching
Scenario: New Context should be enabled
Scenario: Selected facts should be deleted
etc.
问题中概述的场景听起来与系统高度耦合。您指定的行为是什么?
但是,为了适应你所拥有的,我认为这只是一个语言问题。
我个人认为我会将其重命名为:
Scenario: Should be able to delete non-matching facts
它更通用,但仍然可以告诉您当有人阅读场景时发生了什么(考虑到功能的上下文和其他相关场景)。
归根结底,场景名称的长度无关紧要——只要参与开发的人员(想想 3 位朋友、开发人员、测试人员和业务利益相关者)即可;都知道是什么意思。但显然,别人越容易理解越好。