我需要有关如何编写方案的建议。首先，我必须解释一下，我们有一个CQRS架构，其中命令和查询是分开的API。我们使用在Specflow中用于创建测试的Gherkin场景来指定命令。
在下面的场景中，域名是费用。费用包是费用的集合。在这种情况下，我想指定并测试我无法为其他人创建的费用包创建费用。我只能为我创建的费用包创建费用。
以下方法是我尝试重用尽可能多的步骤：
Background:
Given I am declarant 'Marieke'
Scenario: Not allowed to create expense for a bundle that was created by another declarant
Given the following expense bundles exist
| declarant | name | administration | status |
| Lucy | Trip to New York | Company B.V. | not submitted |
When I create an expense for the following expense bundle
| declarant | name | administration | status |
| Lucy | Trip to New York | Company B.V. | not submitted |
Then the expense is not created for the expense bundle
在上面的例子中，名称，管理和状态可能不相关。但在其他情况下，我可以重复使用“给定以下费用包存在”步骤。这为开发人员节省了时间。
在下面的方法中，我尝试编写一个更具可读性和更具体的场景：
Background:
Given I am declarant 'Marieke'
Scenario: Not allowed to create expense for a bundle that was created by another declarant
When I create an expense for an expense bundle that was created by another declarant
Then the expense is not created for the expense bundle
在这种情况下，开发人员必须编写一个可能永远不会再次使用的When步骤。这是一个问题吗？
在我的场景中，我正在努力解决这两个问题。有什么建议？
编写场景的方式也解释了什么和为什么，并且没有任何关于事情如何完成的事情。什么是关于索取费用包，特别是你不能为别人索取费用。你还没有真正解释为什么这很重要，你可以在功能序言中做到这一点。这个场景不应该对费用捆绑是怎么回事。这些场景的其他问题是语言看起来有点笨拙。您可以再次使用序言来解释费用包的含义。所以我会写类似的东西
Feature: Claiming an expense on an expense bundle
Explain what an expense bundle is, including the concept of ownership
Explain what an expense is
Explain why Fred should not be able to claim an expense on Susan's expense bundle
Background:
Given users Fred and Susan
And Susan has an expense bundle
Scenario: Susan claims an expense
When Susan claims an expense on her bundle
Then the expense should be approved
Scenario: Fred claims an expense on Susan's bundle
When Fred claims an expense on Susan's expense bunlde
Then the expense should be rejected
这将是我的出发点，我会用这个来提示问题
如果您正确编写步骤定义，那么当步骤定义重用无关紧要时。编写步骤定义的正确方法是使每个步骤调用一个辅助方法。通过这种方式，步骤定义被简化为执行一个单一功能 - 将业务语言转换为呼叫。因此，如果一个步骤仅使用一次（大多数不是），则无关紧要，因为写入它是微不足道的。
在辅助方法中重用代码是一个完全不同的问题，但现在我们完全使用代码（而不是在步骤def中的一半），我们可以使用所有常规代码工具和技能来解决该问题。
使用场景大纲可能是具有最多可重用代码（步骤）的解决方案。我想我错过了一些关于确切功能的背景信息，但这可能会让你知道如何处理这个问题。这样做的缺点是，当场景中有很多参数时，读取和解释测试结果可能不那么容易，因此它还取决于您的目标以及谁（测试人员，业务人员，开发人员）将创建并解释测试结果。有关场景概述https://www.toolsqa.com/cucumber/data-driven-testing-using-examples-keyword/的更多信息
Abstract Scenario: Don't allow expense creation on bundle of other declarant
Given the expense bundle exists <declarant creator>
When I create an expense for the bundle <expense creator>, <bundle administration>
Then I expect the bundle expense to be <expected>
Examples:
| bundle creator | expense creator | bundle administration | status | expected |
| Lucy | Marieke | Company B.V. | Not submitted | Not allowed |
| Marieke | Lucy | Company 2 V. | Not submitted | Not allowed |
etc..
和快乐的流动
Abstract Scenario: Allow expense creation for blabla
Given the expense bundle exists <declarant creator>, <bundle administration>
When I create an expense for the bundle <expense creator>, <bundle administration>
Then I expect the bundle expense to be <expected>
Examples:
| bundle creator | expense creator | bundle administration | status | expected |
| Lucy | Lucy | Company B.V. | Not submitted | Allowed |
| Lucy | Lucy | Company B.V. | Not submitted | Allowed |
etc..
我会使用第一个选项。更清楚的是什么意思，因为你可以定义另一个声明者是谁。如果开发人员选择使用Marieke作为首选声明者，则测试用例由于不明原因而失败。此外，如果需要，您可以使用其他测试用例扩展您的测试用例，例如“同名，同一管理”。可重用性是自动化的一大优势，它还节省了自己和开发人员之间的通信时间，根据我的经验，这几乎就像自己编写代码一样耗费时间。