Click！-- 在SOAPUI中使用Gherkin

(本文翻译自SmartBear网站博客内容，没有许可，不得转载)

我们时常说到顿悟，那种遇到突如其来的灵感和创意时的感觉会非常棒，是不是？

BDD, Specification-by-example and Gherkin

我做开发已经十年了，就在去年，我开始对软件质量产生了极大的热情，我一直在寻找能够帮助我开发出更高质量的软件的办法。一开始我研究单元测试，随后转向测试驱动开发（TDD），最后我钻研行为驱动开发（BDD）、实例化需求以及类似技术。在我看来，撰写可读性较高的需求并且能够执行和验证是很靠谱的。

为了能够撰写这类需求，我们需要一些工具支持，这类工具有很多。其中一种是Cucumber，从Gherkin语言扩展而来，也就是我们所熟悉的“Given-When-Then”语法。

Gherkin使用三种语法结构来构造需求：

• 特性（Features）
  我们需要实现的需求，例如“登录”、“取款”或者“提交博客”。
  
• 场景（Scenarios）
  需求特性的实例化，有些比较令人愉快，比如“成功登录”，另外一些比较令人不爽，比如“登录失败”或者“无法连接到银行”等。
• 步骤（Steps）
  步骤用来描述该场景的具体操作，一般使用以下三类语法：
  • • Given –指定一些前提条件、上下文，使当前系统进入一个已知的初始状态
    • When – 和系统进行交互的关键操作
    • Then – 预期的执行结果

虽然不是Cucumber用户，我发现这种结构化的需求和测试方式非常自然，只需要一些简单地规则就可以让我在正确的时间专注于正确的事情。

SoapUI

在我所在的公司，我们几年前就开始使用SOAPUI来测试我们的Web服务，从手工测试向自动化测试转变花了很多时间，最终我们终于完成了一定数量的自动化测试用例。有这些自动化测试是好事，但让代码作者和测试人员之间讨论质量时就遇到麻烦了，测试用例的命名就是一个例子：

“老兄，测试用例35刚刚失败了！”
“晕倒”
“是啊”
“那...那个用例是测啥的”
“我去”

看来我们急需一套用例结构来解决这个问题。我开始研究SOAPUI是否可以实现，SOAPUI里有Test Suites、Test Cases和Test Steps。在和这些东东鬼混了一段时间之后，突然我惊奇的发现SOAPUI完全可以使用结构化的方式--一种绿色的方式，一种“蔬菜”方式。

...酷！

Using Gherkin in soapUI

在我看来，Gherkin可以和SoapUI似乎注定是匹配的。他们之间的对应关系如下：

Gherkin construct结构	soapUI结构
特性 Feature	Test Suite 每个特性，我将建立一个Test Suite。这样不仅产生大量的测试套件（suite），通过套件可以很好地形成测试边界。同时可以方便我对测试套件的命名--和特性一样！
场景 Scenario	Test Case 每个套件包含特性相关的测试用例，有些比较开心，有些比较沮丧。我发现在这类用例名称前面使用“Happy-”或者“Sad-"作为前缀可以很容易的区分这类用例。
步骤 Step	Test step 测试用例的每一步都使用”GIVEN“、”WHEN“或者"THEN"的开头来命名。 采用全大写的字体可以使得这种结构更加显著，也许将来SoapUI会使用语法高亮来实现某些功能。。。

An example

让我们以认证服务为例，假设这个服务提供用户登录和授权功能。我们第一个特性是”Login“，以这个名称来创建一个Test Suite：

你也可以在Test Suite属性中来描述该特性的商业价值：

下一步确定一个场景，什么比“成功登录”更有业务价值。我们将创建测试用例，并且标识为“Happy”：

 

最后实现这个例子的具体测试步骤：

 

到此为止，一切就绪！让我们进一步来看具体的步骤的实现：

The Given

我们使用Given来设置初始测试用户。这也许是一个数据库操作，也许是依赖于这个应用环境的一系列服务调用。我一般尽量从一开始就建立测试的上下文初始环境，这样我不会过于依赖于测试环境的数据、系统。我发现使用“Run test case”步骤类型非常有用，这可以方便在测试场景间共享测试代码，很多测试的前置初始化过程非常类似。我使用该测试用例的属性（property）功能来配置特定的用例运行环境，这样被重用的测试用例可以提供我所需要的数据来驱动测试，例如userID。

The When

在面向服务的架构中，When步骤通常是一个service调用。我们将使用参数化的登录方法来调用认证服务，例如UserID=“OurNewlyCreatedUser”。

步骤只是用于和系统进行交互，一般不应该在这些步骤中使用断言。SoapUI提供了简单地断言设置功能，可以直接在SOAP请求步骤进行，但是我们现在需要忽略这种方式，以保持Given-When-Then风格。有时我仅在这些步骤中保留“santity-checks”，例如“Not SOAP fault", 但从来不针对业务功能使用断言。

The Then

这里是我们需要断言的地方，我们需要在Then语句中让测试用例失败，或者更好一些--没有失败...

在soapUI的早期版本中，Then步骤需要我们使用Groovy来进行必要的处理，从4.5版本开始，我们不再需要这样了。我们可以很好的按照Gherkin方式来使用我们的断言步骤。

And…

有了以上这三种结构，使用And可以很方便地增加额外的测试步骤。

我们可以在Given步骤使用And来添加额外的环境设置，在When步骤执行多个操作，或者在Then步骤执行多个断言。在这个例子中，我使用额外的JDBC步骤来确保登录的审计信息已经被保存在数据库中。个人习惯，我尽量限制When和Then的步骤数量，这样可以保持测试用例的粒度，方便用例失败时进行诊断--减少“测试用例35？--我去”的情形。

In conclusion

在soapUI中这么实现真的让我开眼了，我是一个热衷于测试驱动开发的人，但我的测试用例无法让非开发人员理解。由于SoapUI在我的工作中被广泛运用，我现在可以更好地和他们讨论需求和开发状态。这也帮助我更好地让他人理解测试的价值。写测试代码不是分离的活动，也不是需要让其他人来完成的事情。这个开发人员共同的职责，是开发高质量软件的关键步骤。

有许多工具可以实现行为驱动开发（BDD）、需求实例化或类似技术，及时soapUI通常不会被归到BDD工具类别中去，我们在这个上面所投入的时间让他成为一个可行的选择。使用什么工具不重要，重要的是理解需求测试化的意义。

（原文作者：Per Akerberg，原文地址：http://blog.smartbear.com/soapui/click-using-gherkin-with-soapui/）