我有大量使REST調用的speclow/BDD測試用例。這些REST調用適用於內容類型application/json和application/xml。相同Specflow/BDD方案使REST調用首先使用應用程序/ XML，然後使用應用程序/ JSON
但我需要手動更改這些內容類型，並在每次需要測試JSON和XML時重新運行所有相同的場景。
有沒有辦法運行所有場景兩次，首先運行ContentType應用程序/ json和第二次使用application/xml運行。
是的，但是在Specflow中沒有任何東西可以自動支持它。
說了這麼多，你可以輕鬆地重用你的腳步，並喜歡寫東西
Given I am using JSON
And X
When Y
Then it should Z
Given I am using XML
And X
When Y
Then it should Z
甚至
@UsingJSON
Given X
When Y
Then it should Z
@UsingXML
Given X
When Y
Then it should Z
在這裏，您檢測其標籤中的步驟，甚至使用Scoped Bindings使用
有沒有這樣的事情，「BDD測試案例」;只是系統如何運行的例子，我們有時稱之爲「場景」。
我建議首先圍繞使用的不同系統的幾個不同的示例進行一些對話。這將幫助你看到行爲是否真的是一致的。捕獲這些示例還可以幫助未來的開發人員瞭解真正的需求來自哪裏，並設定對哪些源可能使用每種編碼的期望。
如果您真的需要編寫測試，請嘗試在集成測試中包裝代碼的JSON和XML部分。 XML和JSON是技術問題，本地語言真的很難重構！所以可能你想使用像NUnit這樣的東西。
現在你已經有了幾個例子，它們顯示了你的系統如何運行，並且還能夠確保事物的連接正確，還有一些集成測試檢查它是否適用於XML和JSON。集成測試適用於技術人員。如果某個非技術人員確實想要檢查他們是否在工作，只要確保他們的名字正確併爲他們提供了構建的URL。大多數商務人士可以閱讀駝峯案例。
如果您絕對肯定必須同時使用JSON和XML運行每個場景，可以製作「JSON」場景樹和「XML」場景樹，使用符號鏈接或構建腳本來複制文件以確保它們運行來自相同的英語/本地語言源，然後分別提供使用XML或JSON運行的不同步驟定義。不過，我懷疑你對我的第一套建議會比較容易。