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?
可能的选择。
1）领域层。StepsDefs直接委托给服务和仓库。
2）REST层。StepsDefs委托给REST客户端，REST客户端向容器部署的应用发出HTTP请求。
3）用户界面。StepsDefs委托给web驱动，如selenium，并操作用户界面。
PS）欢迎用给定-当-当的符号写出你的答案：)
我认为你问了两个不同的问题，一个在标题，另一个在正文。
可执行的规范应该用对所有相关的利益相关者（尤其是非技术性的）都有意义的领域通用语言来编写。每个场景通常应该验证一个单一的行为，文本应该只包括相关信息--多余的或偶然的细节应该被省略。
检验正确性的标准是 "阅读这个场景的人是否对它感兴趣？" 如果答案是 "是"，你可能会从他们那里得到有价值的反馈。如果答案是 "否"，那么你需要协同完善你的领域语言，并关注他们确实感兴趣的行为。
你可能会发现，你有不同的利益相关者，他们有不同的兴趣。这很好。将场景分离成不同的功能文件，每一个都针对你的一部分利益相关者。把这些文件看作是一个大型印刷手册中不同层次的细节。
技术团队想写的任何测试，如果非技术利益相关者似乎都不感兴趣，可以使用你最喜欢的 "单元 "测试框架来写。你可以使用CucumberGherkin，但为这些测试维护领域语言的成本是否值得？你需要决定。
这个问题与1）是正交的。) 而答案是，一如既往，这取决于。我应用测试金字塔的方法，并偏重于对应用程序行使尽可能少的测试，因为这是有意义的。如果我在测试一个组件的行为，我希望只是通过它所呈现的最简单的界面与该组件进行交互。随着我向金字塔的上升，我开始测试组件之间的协议，最后我确保整个应用程序已经正确部署并 "挂在一起"。
有时候，唯一可用的接口就是UI。这很糟糕，但我们必须忍受它，如果这就是应用程序的方式已经 已经 构建的。这往往会导致可执行规范缓慢而脆弱，需要大量的维护。下一次，从外部驱动开发，并确保你有办法在UI下行使应用程序。
我和@everzet从不同的方向得出的一个技术，就是使用标签来改变StepDefs与应用的交互方式。领域语言保持不变，但标签向测试代码发出信号，是应该通过UI、REST API还是直接调用代码进行交互。
他已经将他的方法记录在 "以身作则". 我用同样的技术在相反的方向，以 重建开发和测试之间的信任 和描述在 黄瓜的Java书