当我们编写包含几个场景的功能文件时，其中包含几个措辞严密，含义紧密的步骤定义，我正在考虑给它们编号。就像方案2的步骤3被命名为s23一样。我尝试这样做...
Scenario: This is my scenario
Given S21the user has some thing
When S22the user does some thing
Then S23we can make sure some thing is anything.
据说这可以帮助我快速识别相应的stepdefinition实现方法，并将控制台日志消息链接到步骤定义等。
但是这导致编号S21，S22，S23等在自动生成的步骤定义中被视为整数参数。如何避免这种情况？
答案 0 :(得分：2)
黄瓜是一种交流工具，而不是一种测试脚本语言。您的企业用户能够理解该表示法吗？这会帮助他们理解情况吗？这种方法违反了Cucumber作为实时文档和通讯工具的目的，应避免使用。如果您的步骤定义不明确，请添加更多上下文（以业务可读语言），以减少这种情况。
您的IDE应该可以帮助您在Gherkin方案和源代码之间切换；您无需在方案中为此添加额外的信息。
您也不需要使用自动生成的步骤定义-为方便起见，您可以编写自己的步骤定义。