在什么地方指定模拟行为在给定的时间-然后语法？

Question

当使用给定的时-然后语法时，我不确定如何在测试场景中指定模拟的行为。在我看来，无论是给予，还是什么时候都是正确的。

请考虑以下示例：

• 我想测试一辆汽车的控制面板。
• 这个面板有一个引擎的开始按钮和一个显示引擎状态的LED。
• 当用户按下“开始”按钮时，引擎应该启动，LED应该是绿色的还是红色的，这取决于引擎是否成功启动。
• 控制面板是SUT，发动机是模拟的。
• 在特定的测试场景中，我们测试引擎启动失败时会发生什么。

下列哪一种时间是比较正确的：

这个：

• 给定处于初始状态的控制面板
• 一台不能启动的引擎
• 当按下开始按钮时
• 然后LED就会变成红色

或者这个：

• 给定处于初始状态的控制面板
• 当按下开始按钮时
• 引擎不能启动
• 然后LED就会变成红色

就我个人而言，我觉得第二种方式读起来更自然，但我也觉得模拟行为不应该是对SUT的行动的一部分。

示例是由组成的，但这里的关键元素是对引擎的操作，该动作是在“时”中给出的测试操作的结果。也就是说，引擎响应不能被表述为状态(除非有人会说“给定一个故障引擎”)。

Answer 1

场景应该在Given步骤中设置。这涉及到对系统部分的嘲弄。但是，当When步骤是操作的一部分时，可以在该步骤中使用模拟。

在阅读两种场景时，它们看上去都像自然语言一样合理：

• 给定一个处于初始状态的控制面板，当按下“开始”按钮时，引擎将无法启动，那么LED就会变成红色。
• 给定一个初始状态的控制面板，当按下“开始”按钮，引擎启动失败时，LED就会变成红色。

然而，第二个变体不符合当时给定的结构.

• 给定描述方案的初始上下文。
• 当描述与系统的操作或交互时。
• 然后描述这些操作的结果。

两种场景都使用被动语态模糊操作：“按下按钮”。根据我的经验，最好是指定一个与系统交互的演员(第三人称视角)，或者从第一个人的角度编写场景：“当司机按下按钮时”或“当我按下按钮时”。

由此可见，“引擎不能启动”并不是一种行动，而是一种结果。但是，将其作为结果断言对于您正在尝试测试的场景来说是毫无意义的。引擎无法启动是场景上下文的一个重要部分，因此应该在Given步骤中指定它。

我会把你的场景写成：

场景:引擎状态LED报告引擎故障。当驱动程序启动时，给定一个控制面板engine和一个坏了的car，那么引擎就会发生故障，引擎状态会亮红。

感谢在评论中指出，仪表板--而不是整辆车--可能是被测试的系统，因此引擎可能是参与者。这将导致以下同样有效的情况：

场景:引擎状态LED报告引擎故障。给定一个控制面板，并且当引擎报告一个failure时，驱动程序试图启动failure，那么引擎状态failure就会亮起红色。

Answer 2

我知道启动一辆车是一个有代表性的例子，所以我将更多地关注这个问题的行为驱动开发和嘲弄方面。

我不知道如何在测试场景中指定模拟的行为.

没有，模拟的行为对场景是透明的。请记住，BDD侧重于业务流程，而不是支持该业务流程的技术细节。

在单元测试中，创建模拟通常是在设置中完成的。这使我相信，给定的步骤会将引擎和控制面板连接在一起，但我不认为用Given an engine后面的And a control panel来描述业务流程。同样，业务流程是重点，它可能包括一个比您最初可能意识到的更大的系统。

连接到控制面板的引擎是最低要求，但不是有用的业务流程。想得更大些。司机需要什么？连接在桌子上的控制面板上的发动机就没那么有用了。司机需要一辆车。整个车辆都是被测试的系统。

现在我们有了一个难题。我们有需要交互的特定组件。其中之一是真正的组成部分。另一个是假的。行为驱动的开发有能力处理这个级别的细节.BDD场景通常用于针对实际系统的端到端测试。如果有任何组件被模仿、存根或伪造，那么它就不是场景中捕获的细节。

我的建议是要么不使用Gherkin，要么将BDD场景的范围限制在控制面板上。将它们限制到这样的程度:每个场景都有一个真正的控制面板，其他一切都是一个模拟。像Given a vehicle这样的步骤可以模拟除了控制面板之外的所有东西。如果您需要测试其他两个组件之间的交互，那么您将需要在一个单独的项目中使用一个全新的特性套件，这样您就可以使用不同的步骤定义来模拟不同的对象。

老实说，我只是不认为这对Gherkin来说是个好用例。这种精细的控制水平只能通过直接的代码来实现。任何涉及Gherkin的解决方案都会影响BDD的最佳实践。虽然没有任何法律会因为违反最佳实践而被违反，但它确实会使像模拟和假货这样的常规测试技术变得非常困难。没有好的答案。Gherkin可能是这份工作的错误工具。

Answer 3

下列哪一种时间是比较正确的：

说到底，这是一个非常乏味的问题。Gherkin (给定的时候)语法的主要受众是人类，人们通常对正确性的困扰远远小于对有用性的关注。

两个有趣的问题是，您的团队和涉众认为哪个版本更容易理解，以及您的工具是否能够处理该顺序子句。

为了明确显示面板可以处理两个事件的序列，我的团队可能会编写测试用例，因为

给定一个初始状态为的控制面板，当开始按钮为pressed时，引擎被请求为start，当引擎失败时，start将变成红色。

这种多事件、多响应的场景在我们所做的测试中是很常见的，但是很难说这是正确的Gherkin语法，有了这两个当时的块。但是，这一结构对我们的用处远远超过它不能被称为正确的事实。