如何在BDD /小黄瓜中描述预期的错误消息

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以获得一些好的指导。