我們正在使用SpecFlow進行功能測試,當人類讀取生成的電子郵件並驗證所有部分符合規範時,這些功能測試會取代手動測試。問題是,方案綱要成爲成長有太多的參數如何解決具有太多參數的SpecFlow場景輪廓?
Scenario Outline: generate and send confirmation email
Given I have stored itinerary in '<EmbeddedItinerary>'
When Generate confirmation email
Then section1 should have parameters '<Param1_1>', '<Param1_2>', '<Param1_3>',...
Then section2 should have parameters '<Param2_1>', '<Param2_2>', '<Param2_3>',..
Then section3 should have parameters '<Param3_1>', '<Param3_2>', '<Param3_3>',...
....
例子:
| EmbeddedItinerary | Param1_1| Param1_2| Param1_3| Param2_1| Param2_2| Param2_3| Param3_1| Param3_2| Param3_3|...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
但列的實例數量將變得難以管理。我希望有多行的例子(但是在Multiple Multi-Line Examples in SpecFlow Feature File中有不同的理由)。
我看到的選項是將所有ExpectedResults存儲在嵌入式xml或json資源文件中,並且SpecFlow功能非常小,例如,
Scenario Outline: generate and send confirmation email with correct email address for flight section
Given I have stored embedded resource '<EmbeddedItinerary>'
When Generate confirmation email
Then sections should be as specified in '<ExpectedResultsFile>'
Examples:
| EmbeddedItinerary | ExpectedResultsFile
| Itinerary_1 | ExpectedResults1 |
| Itinerary_2 | ExpectedResults2 |
...
這是一個好主意嗎?
任何人都可以提出更好的方式(更多SpecFlow風格)? 我擔心的是將預期數據移動到單獨的文件中我失去了可視性,這是SpecFlow功能的優勢之一。
更新:在寫這個問題時,我發現商業產品(每位用戶$ AUD 255)Specflow + Excel http://www.specflow.org/plus/excel/getting-started/,這可能會滿足我的需求來維護許多列。
它是一種成熟/可靠的產品嗎?我應該使用它來代替自己解析專有格式的預期結果文件嗎?
謝謝,安德烈亞斯,我的一位同事想要以同樣的方式。我擔心的是,實際的業務情景是發送包含所有部分的電子郵件,並確保所有部分都正確。你把它分解成單獨的場景來單獨測試每個部分的方法更像是單元測試,我們無論如何(但沒有SpecFlow)。我錯了嗎? –
這取決於您對單元測試Unit的定義。通常它是一個類,所以你正在測試一個沒有依賴關係的類的行爲。如果超過這個參與自動化測試,你就開始稱之爲集成測試。當你正在生成文本和發送電子郵件時,我假設你在這裏有不止一個班級。這意味着你有一個集成測試。 –
如何確定在同一測試中哪些值需要測試,取決於您的代碼。如果您始終獲得某個部分的相同內容,則無論您首先檢查其他部分,如果您在一個場景或多個場景中檢查它們,結果無關緊要。 但是,如果例如第2部分取決於您首先檢查第1部分,然後您需要在一個場景中檢查它們,因爲如果將它們分開,則第1部分是較新的訪問。 –