爲什麼specflow的例子總是使用UI

Question

我新手到BDD試圖理解它。我約BDD的理解是..

「它在那裏使用的用戶specfications測試的種類，產生來自商業的Ubquitious語言「

但是我能夠看到的例子只有UI的例子..就像當按鈕被按下時......當用戶輸入文本時......這不會形成一種語言我可以在我的代碼中使用..

我是否理解這個概念的錯誤

Answer 1

BDD（行爲驅動設計）是由丹北與最佳來源杜撰理解他的意圖，任期爲this excellent blog post

在這裏，您可以讀取丹想從測試的細節焦點轉移到描述行爲改爲。當然這可以（並且肯定已經）以許多方式解釋:)。所以，你會轉向哪裏，你會得到一個自以爲是的觀點 - 這是我的。

基於Cucumber的工具（如SpecFlow）的想法是用語言和工具記下團隊對功能的共同理解，所有相關人員都可以閱讀和理解。這是完成的（再次在基於Cucumber的工具中），通過寫下幾個場景或示例來說明如何使用該功能。一些people通過示例調用該規範。

一些善良出來通過以這種方式使用的例子寫的規格：

• 你可以討論功能的行爲之前，它的實施
• 規格給你一個很大的規範代碼之後，使用outside-in approach
• 規範隨着時間的推移變成迴歸測試，驗證系統的行爲如指定
• 規範也通過舊的TDD承諾併成爲系統的生動文檔。你可以很容易地看到一個功能的當前狀態是看該功能已通過

所以，現在終於到了你的問題可執行的規範是什麼（它的方式是一個偉大的，我經常問自己和別的）。不好意思，我希望我抓住你的意圖：

我的場景是否必須（或應該它們）針對UI運行？

您當然不需要針對UI運行場景 - BDD的原則和工具在任何層面都很適合您的域。

但爲了充分利用您的技術指標，您應該考慮以上我的（不確定）列表。如果您不包括GUI（或數據庫，或服務等），那麼您無法確定整個應用程序堆棧是否可以正常工作。所以很多時候規格都是端到端運行的。

這使得這些「測試」與你的單元測試（你想快速閃電，嘲笑外部依賴，不碰數據庫等）有很大不同。他們需要更長的時間來執行，所有這些都不應該在每次登機時運行，不要使用模擬等。

通常，您首先需要一個場景的步驟，並作爲行爲的驅動程序，然後使用普通的TDD來驅除系統內部的細節。這是外部編程。

最後以上例爲例。所以我建議你在數據庫中一直運行你的端到端規範，但我會建議用上述技術術語描述UI（例如使用按鈕，鏈接和文本框）。當我在BDD Google Group上提出這個問題時，我從Elisabeth Keogh得到了一個很好的提示：

不描述UI。請描述你想用UI實現的目標。

所以形容登錄功能不寫：

Scenario: Login (describing the UI) 
    Given I am on the Login-page 
    When I enter 'AUser' in the textbox 'UserName' 
     And I enter 'APassword' in the textbox 'Password' 
     And I click the 'Login' button 
    Then I should see the following text 'You are logged in' 

而寫是這樣的：

Scenario: Login (describing what we want to achieve) 
    Given I am not logged in 
    When I log in using 'AUser' and 'APassword' 
    Then I should be logged in 

剩下的複雜性上如何做到這一點（點擊按鈕，填寫表格，檢查信息等）是在代碼中編寫的步驟定義中完成的。

我希望這是有幫助的。另外，我正在爲自己的一些「抨擊」而自豪，這些「抨擊」可能來自其他更有經驗的BDD人。但是，嘿，這是我的兩美分:)

Answer 2

我對BDD和Specflow還是很新的。我們一直在使用它來建立行爲並對控制器進行編碼，這反過來驅除了觀點。我沒有在我面前的代碼示例，但我會嘗試找到要稍後發佈的內容。乾杯!

編輯 - 順便說一句，如果你正在尋找一本好書利用黃瓜（它使用相同的語言Specflow - 小黃瓜，我仍然得到所有的作品直），我強烈推薦的RSpec Book來自Pragmatic Programmers。代碼是基於Ruby的，但是有一些關於項目定義和運行的更高層次的章節。非常值得的價格。