3
在Specflow中，可以使用dependency injectionSpecflow中的依赖注入，它是每个功能的一个上下文对象吗？
在步骤定义之间共享上下文这是否意味着您最终为每个功能部署了不同的“上下文”类？
如果是这样，这是不是不可能跨功能共享步骤定义？你认为领域已经设置？
A
回答
1
这是否意味着最终每个功能都有不同的“上下文”类？
我不认为这会是这种情况。在编写规范时，您肯定会提到系统中的几种“种类”部分。比方说，我们有以下情形：
Scenario: List todo items
Given I'm registered as [email protected]
And I'm logged in as [email protected]
And I add a todo item with the text 'Listen to stackoverflow podcast'
When I list all my todo items
Then I should see the following items
| Text | Completed |
| Listen to stackoverflow podcast | false |
在这种情况下，我们与系统的几个部分进行交互：
- 注册
- 认证
- 的TodoItem创作
- 的TodoItem上市
Wh恩实现此功能的步骤中，我们可能会落得这样一个组织步文件：
AuthStepsGiven I'm registered as __Given I'm logged in as __
TodoItemsStepsI add a todo item with the text '__'When I list all my todo items 使用上下文注入
Then I should see the following items
在这种情况下，我们想分享的CurrentUser的价值才能够说这样的话：“当我列出所有我的待办事项“，指的是当前用户。这样任何其他stepFile中的其他步骤都可以是前面步骤的上下文。
另一方面，我不会使用上下文注入与When I list all my todo items的结果，因为只有共享这些功能特定问题的步骤才会在同一个功能文件中。您可以有then“声明”的多种变体，如Then I should see n items。
尽管我确实认为你可能有多个类使用上下文注入来共享你正在构建的服务的依赖关系，或者服务本身（存储，会话等）。）
1
对象的生命周期是根据情景。这意味着，您可以为每个场景/测试获得一个单独的实例。
这样你就不能在不同的测试之间共享一个状态，所以它们不能相互影响。
1
恕我直言，你应该在系统中使用基于'域'的上下文，而不是基于你测试的功能。
我们发现，像这样的上下文提供了良好的关注封装并且更合乎逻辑。所以你可能有一个UserContext,CartContext, PaymentContext等，然后你需要在这些上下文中的函数或数据的步骤在构造函数中请求它们。
正如Andreas所说，specflow将管理您的上下文，以便在每种情况下将它们隔离开来。
0
它不依赖于功能。每个场景都有自己的上下文，并且随着场景结束而结束，不同的功能可以使用相同的上下文
你是什么意思“你假定字段已设置”？你是指在步骤文件中的私人领域？ –