如何在 BDD / Gherkin 中描述预期的错误消息

Question

我们公司刚刚开始使用 BDD，目前正在尝试编写我们的第一个功能。我们创建了如下内容：

Feature: There can only be one
It is important that there is only one Highlander in the system for a given time period.

Scenario: Inserting a new Higlander for a time period already taken by another 
Given there is a Highlander Adam in the system for time period 1820-1900
When I insert a Higlander Bert for time period 1800-1900
Then the System raises Error Code "ONLY1"  

Scenario: Inserting a new Higlander for a free time period
Given there is a Highlander Adam in the system for time period 1820-1900
When I insert a Higlander Bert for time period 1901 - 1902
Then the System raises no Error

我的问题是关于第一个场景中的错误代码 (ONLY1)。目前，我们的系统出现了很多错误，但我们没有一种识别特定错误情况的简单方法。我们的系统已有 15 年以上的历史。这么多年我们都没有发现这是一个问题，这不是很有趣吗？我发现 BDD 非常明显，以至于我们需要一种清晰的共享语言来识别我们的错误消息。

我的一些同事认为不需要错误代码。这意味着我们必须这样写断言：

Then the System shows the error "There can only be 1 Highlander for a given time period."

这让我感到畏缩，因为

如果我们稍后决定将文本更改为其他内容，测试将会中断
只有英文版本的软件才能测试成功（我们支持多国语言）
错误代码非常适合在知识库或支持票中查找信息。

当然，我们应该显示错误代码和用户语言中可读的错误描述，但在测试规范中，我更愿意只提及错误代码。

你如何测试错误？您使用代码或例外还是纯文本？

最好的问候垫子

Answer 1

严格来说，从 BDD 的角度来看，您希望专注于预期的行为。让你的测试没有技术细节。也就是说，错误代码是技术细节。尝试遵循 BDD 时，请避免在功能文件中出现错误代码。而是将错误代码放在您的步骤定义中。

但用户友好的错误消息略有不同。向最终用户显示的错误消息不是与错误代码或枚举相同意义上的技术细节。这是最终用户应该理解的东西。如果他们不理解用户友好的错误消息，那么它就不是用户友好的，应该重写直到它是。所以你下面的例子是完全有效的 BDD:

Then the System shows the error "There can only be 1 Highlander for a given time period."

您也应该了解这种方法的缺点。对消息术语的任何更改都意味着您需要更新引用此消息的所有测试。虽然将消息放入您的特性中可能不会违反 BDD，但它确实会使您的测试套件维护起来更加费力。更好的断言可以捕获行为的本质，而不需要场景作者知道用户界面的确切细节：

Then the system says there can only be 1 highlander

步骤定义随后可以自由使用错误代码、枚举或 UI 错误消息作为断言的一部分。这在行为的实现和描述之间提供了一个抽象层。 UI 或不影响整体行为的代码的功能更改可以在一处修复。

查看 BDD 101: Writing Good Gherkin 以获得一些好的指导。

如何在 BDD / Gherkin 中描述预期的错误消息

How to describe expected error messages in BDD / Gherkin

bdd

specflow

gherkin