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
它不依賴於功能。每個場景都有自己的上下文，並且隨着場景結束而結束，不同的功能可以使用相同的上下文
你是什麼意思「你假定字段已設置」？你是指在步驟文件中的私人領域？ –