空手道DSL是否可以从更高级别的cucumber场景中调用？

Question

我发现非常有用的一种模式是在功能文件中保留特定于业务/相关的场景。然后，在步骤定义中执行所有技术操作，如特定的REST调用和断言。

下面是我想要达到的大致目标的一个例子。这可能不是一个特别好的例子，但我需要一些东西来描绘一幅图画，让人们以类似的方式思考。

场景：搜索给定的技能“Bob”有“空手道”作为技能，“BDD”是可用的技能，而“Bob”没有“BDD”作为技能。当Jane搜索“Bob”的技能时，她将看到“空手道”而不是“BDD”

然后我想要从BDD场景中获得步骤定义。

^给定（.）has（.）作为给定url“http://myhost.com/packetists”和请求“{name：”${1}“.skills：[”${2}“]}”的技能$,当方法post Then状态201和响应=={id:'#NotNull',name:'${1}‘,skills：[“${2}”]}

^And(.*)是给定url“http://myhost.com/skills”和请求“{skills:[”${1}“]}”的可用技能$，此时方法post Then状态201和响应=={skills:[“${1}”]}

^和（.）没有（.）作为给定url“http://myhost.com/candidates/${1}”和请求“{name：”${1}“的技能$，当方法get Then status 200且响应==(Todo:assert${2}不在技能列表中...抱歉，没有时间查找有效的空手道语法）时，技能:[”${2}“]}”

^When.*搜索(.*)的技能$给定url“http://myhost.com/candidates/${1}”When方法get

^Then.*将看到(.*)$然后响应=={id:'#NotNull',name:'#NotNull',skills:[“${1}”]}

^且不是(.*)$然后响应==(TODO：检查它没有${1}作为技能）

我意识到我的例子有些复杂。例如，前3个步骤定义完全包含了G/W/T。其中，作为最后3个步骤定义，在G/W/T上划分为3个步骤定义。

提前致谢

Answer 1

然后，当我看到“要维护的单层代码”被作为特性进行营销时，我感到很难过，业务不关心的技术API被推到特性定义中。

是的，这是有意的，希望我能让您相信为什么会通过另一个堆栈溢出来完成这个操作：https://stackoverflow.com/a/47799207/143475

现在，我想考虑一下你所说的“两全其美”的问题。我们正在进行引擎重写，您可以在这里找到与您的问题相关的动机和一些活跃的辩论，请访问:https://github.com/intuit/karate/issues/398

但第一个环节应该解释为什么我认为这不是优先事项。我相信空手道不应该解决“非技术使用者的阅读能力”。

也许，对您来说最好的情况是，在引擎重写之后，您将能够以最小的侵入性方式将空手道混合到“传统cucumberBDD”测试中。可以自由地参与并塑造它应该看起来的样子。