Question

我需要有关如何编写方案的建议。首先，我必须解释一下，我们有一个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

在这种情况下，开发人员必须编写“何时”步骤，该步骤可能永远不会再次使用。这有问题吗？

在我的方案中，我经常为这两种选择而苦苦挣扎。有什么建议吗？

Answer 1

编写方案的方法也解释了原因和原因，而对如何完成工作一无所知。 WHAT与索偿费用捆绑有关，尤其是您不能为其他人索偿费用。您尚未真正解释为什么重要，您可以在功能序言中进行说明。该方案不应对HOW费用捆绑有多大影响。方案的其他问题是该语言似乎有点笨拙。同样，您可以使用前言来解释什么是费用捆绑。所以我会写类似

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

这将是我的出发点，我将用它来提示类似的问题

为什么Fred可以看到Susan的费用组合
当弗雷德试图索要费用时，我们是否应该通知某人（苏珊，弗雷德斯的老板，弗雷德）
...

如果正确地编写了步骤定义，则在阻塞步骤定义的重用无关紧要时。编写步骤定义的正确方法是使每个步骤都单独调用一个辅助方法。这样，将步骤定义简化为执行一个功能-将业务语言转换为呼叫。因此，步骤只使用一次（大部分都不使用）并不重要，因为编写该步骤很简单。

在辅助方法中重用代码是一个完全不同的问题，但是现在我们已经完全掌握了代码（而不是一步一步地完成工作），我们可以使用我们所有的常规代码工具和技能来解决该问题。

Answer 2

使用方案提纲可能是具有最多可重用代码（步骤）的解决方案。我想我缺少有关确切功能的上下文，但这可能会让您知道如何实现此功能。不利的一面是，当场景中有很多参数时，读取和解释测试结果可能并不那么容易，因此它还取决于您的目标以及由谁（测试人员，业务人员，开发人员）创建并解释测试结果。有关方案概述的更多信息 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..

Answer 3

我会使用第一个选项。更清楚的是什么意思，因为您可以定义另一个声明者是谁。如果开发人员选择使用Marieke作为声明声明，则测试用例由于不清楚的原因而失败。另外，如果需要，您可以使用其他测试用例（例如“相同名称，相同管理”）扩展测试集。可重用性是自动化的一大优势，它还节省了您自己与开发人员之间进行通信的时间，以我的经验，这几乎与自己编写代码一样耗时。

小黄瓜方案，可重用步骤方法或特定方法

3 个答案: