黄瓜是一种规范语言的执行框架。 它并不是要成为测试语言，而是用于创建测试自动化。

黄瓜最适合出现一些现实世界中的参与者互动并取得某种成果的情况。 当可以从用户的角度编写它时，它特别有用。

 Given Sarah is a premium club member  When Sarah logs into the homepage  Then she sees the premium club member call to action 

尽管这可能是关于屏幕的讨论，但它也以用户和产品的语言进行讨论。 这是一个舒适的规格。

谁是后端用户？

假设我们要在Cucumber中为后端编写API测试？ 这给我们带来了一些问题，例如，它实际上是一个不一定使用用户语言的较低级接口，或者我们必须跟踪发出的请求的状态，因为我们不能仅仅谈论正在处理的内容。屏幕。

那我们应该吗？

Cucumber是编写API测试的错误工具吗？

答案在于我们是否认为后端具有可以以人类可读形式表达的规范。

我们认为后端有规范吗？

让我们承认，无论规范是什么，它都是比功能级验收测试更具技术性的语言，而功能级验收测试可能与此后端只是组件的业务流程有关。

这里的一些问题是写作。 我们希望以简洁的形式表达系统的预期/期望行为。 这是我们需要求助于写作1-2-3的地方 。 每个故事都有一个起点和终点。

您将如何向为您的工作付费的人解释给定API的目的是什么？

好吧，这个API是一个基于接收到他们的凭据为用户生成用户登录证书的API，假设该用户对凭据数据库是已知的，否则就不会……

好吧..还有一点点不足，但至少听起来很有价值。 我们可以1-2-3吗？

对于已知用户，提供凭据将产生证书。

在小黄瓜中：

 Given Sarah is known to the credentials database as "sarah" with password "s4r4h"  When Sarah's sign- in request is submitted as "sarah" , "s4r4h"  Then a certificate is returned  And the certificate contains the name "Sarah" 

从哪儿开始？

制作的示例很简单……您如何开始呢？

这里有一些想法：

• 绘制您要测试的服务的图表
• 确定图中的哪些对象是测试的目标，哪些是以下两者之一：
  • 服务的消费者
• 考虑通过服务的数据流：
  • 您如何开始？

现在我们了解：

• 服务的外部触发器/客户端
• 服务返回的东西
• 服务需要发生以支持它的事情
• 服务对外界所做的事情

我们的规格应为上述术语。

奖励功能

我们的测试设计应该能够解释自动化将如何以客户端的身份使用服务，提供任何依赖关系以及观察服务的副作用和响应。

翻译自: https://www.javacodegeeks.com/2020/02/how-to-phrase-back-end-tests-in-cucumber.html