您的BDD規格應該與UI測試分開嗎？

昨天我通過Gojko Adzic瞭解了關於BDD的很棒的演示。我可能會錯過他說的一兩件事，所以這裏有一個問題，希望能夠爲我解決一些問題。您的BDD規格應該與UI測試分開嗎？

通常，當您在線看到BDD示例時，他們在UI中包含了一些步驟。在一個黃瓜語言，你可以經常看到類似的東西：

Scenario: Successful booking 
    Given I am on the page ... 
    When I enter the following ...

或類似的東西。

我的問題是，這真的與BDD有關嗎？ BDD不應該針對該領域，然後通過UI或迴歸測試來進行這些測試。我所想的是像這樣利用小黃瓜的語法來描述預訂系統的somekind的：

BDD規格：

Scenario: Successful booking 
    Given I am an authenticated user 
    When I place an order with the following items 
     | item | price ($) | 
     | book1 | 5   | 
    Then I should expect to pay $5 
    And I should get a confirmation mail of my order

請注意，我不是mentoning的UI可言，我只是描述瞭如何域的作品，這個測試應該在每一個版本上運行。然後，你可以有你的UI測試（也小黃瓜）：

Scenario: Successful booking 
    Given I am logged in on the site 
    And I go to the page for item book1 
    And I click add to basket 
    Then I should have a basket with 1 item and $5 
    When I click checkout 
    Then I should get to the checkout page

和再這樣下去，也許應該分爲兩個或三個方案但這不是重點。這類測試的運行較爲繁重，應該只能在夜間測試中運行。問題的關鍵仍然是：你是否應該將BDD規範與UI /迴歸測試分開？

來源

2011-10-26 Tomas Jansson

既然你指的是Gojko Adzic，讓我從他的書「規範範例」中引用一句話：「不要被困在用戶界面的細節中，用戶界面是可視的，所以很容易思考。我已經看到了團隊和客戶花費數小時來描述導航菜單鏈接的項目，但這部分用戶界面幾乎沒有風險，並且可能花費了時間來討論更重要的功能 [...] –

（quote繼續）：「而不是停留在用戶界面的詳細信息，而是考慮通過網站的用戶旅程更有用。在協同指定時，根據其對業務的重要性，按時間投入部分規格。應該詳細探討重要和有風險的項目。那些不重要的可能不需要如此精確地指定。「 –

總而言之：BDD規範不需要用UI來表示，而且UI測試通常是端到端測試，它是 –

不推薦嘗試分離出域和UI測試。

使用Cucumber的一大優勢是您的規格（測試）可以被非技術方面的利益相關者閱讀和理解。那些人可能不太在意用戶界面的細節。

所以一個好的方法是簡單地將用戶界面的東西向下推到一個圖層的步驟定義中，例如，

Given /^I place an order for "([^"]*)"$/ do |item| 
    visit catalog_url 
    click_link item 
    click_button "Add To Basket" 
    click_button "Submit Order" 
end

來源

2011-10-26 12:10:17

但是，非技術性利益相關者關心您點擊的鏈接或按鈕？利益相關者關心域名，他們關心建立訂單，下訂單並獲得訂單付款 –

這正是我想說明的 - 這是步驟定義，只有名稱「給定我爲X下訂單」出現在功能文件中，因此您的利益相關者將看不到實施細節。 –

爲什麼不建議分開域和UI測試？ –

BDD歸結爲質量保證其他非技術人員與使用本機語言作爲功能定義的開發人員之間的協作。所以從這個角度來看，你的兩個例子都可能被利益相關者理解爲一個特徵。

但是總的來說，你可以使「故事」越抽象，越好。這種差異或潛在的問題並不是提到UI，而是關於佈局的潛在假設和討論。應用程序的初始工作流程可能會發生變化，因此功能定義中的更改可能需要與主持人進行新的討論。如果目標保持不變，那麼可能並不需要談判。

也就是說，實用性會很快發揮作用。一個不明確的特徵定義需要對ui進行更精確的定義，然後將其轉換爲步驟定義或使用其他UI測試工具編寫的測試。編寫功能文件的實際步驟定義是最困難的部分，因此，只要具有一套完整的步驟定義，編寫新的方案就相當快速。不要在UI測試中重複使用這些東西看起來很浪費，所以我們在UI測試中使用相同的集合。

我們將UI測試分開，只是在並非所有場景都與賭注持有者討論的意義上。最重要的標記，每個功能有一個或兩個scnearios標記，其餘都是UI測試。此外，有時功能文件不是由編寫步驟定義的人編寫的，因此這允許UI測試編寫者不太瞭解如何在使用的框架中實現UI操作的具體知識。

來源

2011-10-27 11:07:13

您的BDD規格應該與UI測試分開嗎？

回答

相關問題