运行cucumber测试的正确抽象级别是什么？

可能的选择：

1） 域层：StepsDefs直接委托给服务和存储库

2） REST层：StepsDefs委托给REST客户端，该客户端在容器部署的应用程序上触发HTTP请求

3） 用户界面：StepsDefs委托给web驱动程序（如selenium）并操作用户界面

---

PS）请在给出答案后用注释：）

我想你在问两个独立的问题，一个在标题中，另一个在正文中

1） 什么是“正确”的抽象级别？ 可执行规范应使用对所有相关涉众（尤其是非技术性涉众）都有意义的领域/普遍语言编写。每个场景通常应验证单个行为，文本应仅包含相关信息-应忽略冗余或附带的细节

正确性测试是“阅读此场景的人对它感兴趣吗？”如果答案是“是”，您可能会从他们那里得到有价值的反馈。如果答案是“否”，那么您需要协同改进您的领域语言，并关注他们感兴趣的行为

你可能会发现你有不同的利益相关者，他们有不同的兴趣。那很好。将场景分为不同的功能文件，每个功能文件都针对您的利益相关者。可以将这些视为大型印刷手册中不同层次的细节

技术团队想要编写的任何非技术涉众似乎不感兴趣的测试都可以使用您最喜欢的“单元”测试框架编写。您可以使用Cucumber/Gherkin，但是为这些测试维护域语言的成本值得吗？你需要做出决定

2） STEPDEF应如何与应用程序交互？ 这个问题与1）正交。答案是，一如既往，这要视情况而定。我采用了测试金字塔的方法，并倾向于使用尽可能少的应用程序进行测试。如果我正在测试一个组件的行为，我希望通过它提供的最简单接口与该组件进行交互。当我沿着金字塔向上移动时，我开始测试组件之间的协议，最后我要确保整个应用程序已正确部署并“挂起”

有时唯一可用的界面是UI。这很糟糕，但如果应用程序已经以这种方式构建，我们就必须接受它。这通常会导致需要大量维护的缓慢而脆弱的可执行规范。下一次，从外部推动开发，并确保您有在UI下运行应用程序的方法

@everzet和我从不同的方向达成的一项技术是使用标记来改变StepDefs与应用程序交互的方式。域语言保持不变，但是标记向测试代码发出信号，指示它是否应该通过UI、RESTAPI或直接调用代码进行交互

他已将自己的方法记录在一份报告中。我使用了与中描述的相反方向的相同技术

Given a java web application
And that it has a restful back-end
And serves a single page html/js front-end
When I use cucumber to test my application
Then which layer should I drive my tests through?