【问题标题】:How to teardown a specflow scenario如何拆除 specflow 场景
【发布时间】:2016-07-17 00:54:22
【问题描述】:

我正在尝试创建一组新的测试来测试我正在开发的旧网站。该站点在后端使用数据库。我正计划使用 SpecFlow 和 Selenium,但我有点不知道处理数据清理的最佳方法是什么。

目前我有一个数据库备份,其中包含一组示例数据,我在每次测试运行之前都会还原这些数据。然而,这很麻烦,所以我只想在发布前对关键测试运行执行此操作,并让持续集成运行在其间的同一数据库上运行。

目前我有大量类似这样的测试:

Secenario: Test Item Creation
    Given I am logged in
    When I create an item with a unique name
    Then an item exists with the unique name

when 步骤使用 GUID 来确保名称是唯一的,然后 then 步骤可以通过模块变量访问它以检查它是否存在。

就像我说的,但是我有很多与此类似的测试,并且我在同一个数据库上多次运行它们,因此测试系统充满了降低搜索速度等的项目。

我的问题是处理这个问题的最佳方法是什么?我是否应该在测试中创建另一个步骤,像这样再次删除该项目:

Secenario: Test Item Creation
    Given I am logged in
    When I create an item with a unique name
    Then an item exists with the unique name
    Then delete the item with the unique name

或者我的测试框架应该能够以某种方式处理这个问题吗?如果是这样,人们会怎么做?鉴于 SpecFlow 步骤的全局性质,我想如果具有父子关系的多个项目可能会出现问题,那么以正确的顺序获取拆卸步骤。

【问题讨论】:

    标签: database specflow test-data scenarios teardown


    【解决方案1】:

    一个好的测试应该没有依赖关系,因此创建测试步骤然后“拆除”测试数据是个好主意。

    您可以采取的一种方法是存储由以下人员生成的唯一名称:

    When I create an item with a unique name
    

    ScenarioContext 对象中,例如

    ScenarioContext.Current["testItem"] = "testItemName";
    

    这将允许您在场景期间保持此值。

    然后,您可以创建一个与特定标签关联的SpecFlow hook,以在场景完成时删除此数据,例如场景将是(注意标签):

    @deleteTestItem
    Secenario: Test Item Creation
    Given I am logged in
    When I create an item with a unique name
    Then an item has exists with the unique name
    

    要清理的代码是:

    [AfterScenario("deleteTestItem")]
    public void DeleteTestItem()
    {
     var testItemName = ScenarioContext.Current["testItemName"];
    
     // Use testItemName to clean-up your database
    }
    

    然后,此代码将仅针对具有此标记的场景运行。请注意,如果您的所有测试都涉及创建测试项,那么您可以省略标签并简单地使用 AfterScenario 挂钩。

    或者,您可以将所有测试项目名称保留在 FeatureContext 中,然后在 AfterFeature 挂钩中删除这些项目。这将导致更少的数据库调用(即您不会在每个场景之后调用数据库进行清理)。

    我更喜欢 ScenarioContext 方法,因为我觉得如果一个 Scenario 创建数据,那么该场景应该负责自行清理。

    【讨论】:

    • 我更喜欢一个显式的上下文对象,它通过上下文注入通过步骤类的构造函数传递并在那里填充,而不是使用ScenarioContext.Current(不能在并行测试中使用) specflow 2.0),但这基本上是我觉得正确的方法。
    • @SamHolder ScenarioContext.Current 是一个明确的上下文对象,即它是该场景实例独有的。并行测试有什么问题?
    • 是的,我了解ScenarioContext.Current 是什么,我只是认为它不是在 Specflow 中的步骤之间共享状态的最佳方式。有basically 3 ways,对于特定状态使用显式类而不是使用通用ScenarioContext 更可取恕我直言。在给出的示例中,我可能会创建一个带有属性NameItemContext 类,我会将其设置为Guid。然后,您可以以类型安全的方式使用此类,而不是依赖于 ScenarioContext.Current 的基于字符串(和强制转换)的方法
    • 您可以看到新的并行测试支持here 的文章。我认为它解释了在这个新范例中使用 ScenarioContext.Current 的问题以及建议的解决方案是什么(即注入 ScenarioContext 的实例),但恕我直言,如果你打算这样做,你不妨创建一个特定的上下文具有强类型优势的对象
    • 并且明确的上下文我并不是指特定于该场景,我指的是特定于特定任务(即在这种情况下持有对创建的项目ID的引用)。但是很好的答案,我只是指出了其他选项,因为我不认为使用 ScenarioContext 是一种好习惯(我希望它在 2.0 中消失,但是嘿嘿!)
    猜你喜欢
    • 2018-09-24
    • 1970-01-01
    • 1970-01-01
    • 2023-04-02
    • 1970-01-01
    • 2018-03-10
    • 2014-10-12
    • 2018-10-08
    • 2021-04-29
    相关资源
    最近更新 更多