我們應用程式的基礎是一個大型配置集，它定義了抽象的設備組，它們作為 Gherkin 場景的一部分無處不在。
現在我們在 Gherkin 規范中使用了像這樣的 Given 步驟：
Given the device is a Zebra
在這種情況下，Zebra 只是實際組的占位符，但它包含許多不同的特定設備。像這樣的陳述句非常方便，但它也使這個場景無法測驗，因為您必須為每個特定設備自動執行這個場景，而且我不知道有任何框架具有這樣的功能。并且場景大綱也不是解決方案，因為您將在幾乎所有場景和/或功能檔案中擁有此設備串列的副本。
這個問題有沒有可能的解決方案。也許我們這樣使用 BDD 是完全錯誤的，但是你怎么能處理這種配置問題呢？
uj5u.com熱心網友回復：
如果您只想在特定型別的所有場景之前設定一個背景關系（您的設備串列），那么這是一個非常好的背景背景關系示例；很少更改并且適用于所有場景的長期資料。許多 BDD 框架提供工具，使您能夠在功能/場景檔案的頂部設定背景。例如 Cucumber 有Background；JBehave 使用 GivenStories 做到這一點。
對于不提供此類工具的框架，可以跳過該步驟的細節，只要每個使用它的人都能很好地理解它。所以你可以例如說：
Given the standard device list
And a Zebra from that list
這將允許您只用幾行來完成它，設備串列的詳細資訊隱藏在步驟定義中。
但是，如果您希望嘗試為每個設備運行場景以檢查其是否正常作業，那么這可能超出了 BDD 的范圍，當然也超出了 BDD 框架的范圍。
BDD 并不是關于嚴格的回歸測驗。它是關于捕獲系統行為方式的具體示例，最好通過與專家（了解問題的人，如業務代表）、測驗人員和開發人員的對話。如果您有一個設備以特定方式運行的示例，則通常足以理解這種理解，至少從 BDD 的角度來看是這樣。
如果您必須為每臺設備執行一個場景只是為了徹底，那么可以改用 JUnit 之類的東西。如果你愿意，你仍然可以使用 Given / When / Then 語法，或者作為代碼中的注釋或者通過創建你自己的 DSL，但是如果你找到其他方法來表達測驗的價值，那么就不要受 BDD 的約束語法或 BDD 工具。這不是測驗事物的唯一方法。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/478731.html