我目前正在學(xué)習(xí)黃瓜，在非常簡單的測試中，我有一些疑問：“如何組織我的StepClasses的最佳方法。這是我的.功能：Feature: How many potatoes have in the sackScenario: I put one potato in the Bag Given the bag has 10 potatoes When I put 1 potato Then I should be told 11 potatoes Scenario: I remove one potato from the Bag Given the bag has 10 potatoes When I remove 1 potato Then I should be told 9 potatoes還有我的階梯班：公共類步法 {private Integer potatoesInTheBag;@Given("^the bag has 10 potatoes$")public void the_bag_has_10_potatoes(){ this.potatoesInTheBag=10;}@When("^I put 1 potato$")public void i_put_one_potato(){ this.potatoesInTheBag = potatoesInTheBag + 1;}@Then("^I should be told (\\d+) potatoes$")public void i_should_be_told_potatoes(int potatoes) throws Exception { assertEquals(potatoesInTheBag.intValue(),potatoes);}@When("^I remove 1 potato$")public void i_remove_one_potato(){ this.potatoesInTheBag = potatoesInTheBag - 1;}}此示例工作正常，但是i_remove_one_potato（） 應(yīng)該留在這里，還是留在另一個步驟類中？另一個問題，如果我想使用場景大綱，在這種情況下我會怎么做？因為答案會有所不同，盡管添加/刪除的馬鈴薯是相同的。有一些好的實踐可以指導(dǎo)構(gòu)建黃瓜測試的過程？
2 回答
長風(fēng)秋雁
TA貢獻(xiàn)1757條經(jīng)驗 獲得超7個贊
就 Step 與要測試的方案相關(guān)而言，最好在單個 Step 類文件中找到這些步驟。對于場景大綱，它可以是這樣的：從袋子中添加/刪除土豆。
：在給定袋子有“10”個土豆而不是你使用它的一個場景中使用變量，從長遠(yuǎn)來看會有所幫助。
慕容3067478
TA貢獻(xiàn)1773條經(jīng)驗 獲得超3個贊
關(guān)于如何構(gòu)建功能文件和步驟定義，有很多不同的意見，其中很多都?xì)w結(jié)為偏好和項目的需求。我在這里的所有想法都是關(guān)于通過瀏覽器對大型項目進(jìn)行系統(tǒng)測試的，這可能與每個人無關(guān)。
也就是說，我運(yùn)氣最好，功能與步驟之間存在1對1的關(guān)系。我喜歡使用一個步驟 def 來提供單個功能文件，并避免重用步驟作為保持代碼 DRY 的主要策略（這就是頁面對象的用途！偶爾重用一個步驟是有意義的（例如，鑒于我已經(jīng)登錄），但我的經(jīng)驗是，它會導(dǎo)致建立這些非常小的原子步驟的大庫，這些步驟很難找到，難以重用，并將小黃瓜推向極致。
1對1方法（除了在黃瓜文檔中違反這種反模式之外）的明顯抱怨是，它會導(dǎo)致重復(fù)的代碼，但我發(fā)現(xiàn)任何你想多次做的事情都可能是一個通用的操作，可以向下推送到頁面對象。這在步驟定義中留下的很少，除了特定于正在測試的業(yè)務(wù)規(guī)則的代碼，無論如何您都不需要復(fù)制這些代碼。
如此簡短的回答，我將與該功能的其他步驟保持在同一類中。但就像你說的，你的例子很簡單，所以我猜測你的項目最終會是什么需求。i_remove_one_potato()
例如大綱，您應(yīng)該能夠執(zhí)行如下操作
Scenario Outline: I add/remove potatoes from bag
Given the bag has <initial> potatoes
When I <add_remove> <delta> potatoes
Then I should be told <outcome> potatoes
Examples:
| add_remove | initial | delta | outcome |
| add | 10 | 1 | 11 |
| add | 10 | 10 | 20 |
| remove | 10 | 1 | 9 |
| remove | 10 | 10 | 0 |
我盡量不要用場景大綱過度使用它，但這可能走得太遠(yuǎn)了。將整個功能歸結(jié)為一個由通用步驟驅(qū)動的編程表可能很誘人，但在某些時候，很難提取出各個業(yè)務(wù)規(guī)則是什么。當(dāng)一個示例開始失敗時，您必須將整個事情分開，并找出作者為什么選擇他所做的表值。BDD工具應(yīng)該照亮該功能，而大型表格往往會掩蓋它。對于上面的示例，我可能應(yīng)該將添加和刪除拆分為單獨(dú)的大綱，因此我不會將不同業(yè)務(wù)規(guī)則的示例混合在一起。
添加回答
舉報
0/150
提交
取消