正文：

　　Behavior Driven Development，行為驅動開發是一種敏捷軟件開發的技術，它鼓勵軟件項目中的開發者、QA和非技術人員或商業參與者之間的協作。
在了解Behavior Driven Development之前，先介紹Test-Driven Development(TDD)即測試驅動開發，它是一種測試先于編寫代碼的思想用于指導軟件開發。測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什么產品代碼。

TDD方法的一些特點：

• 有利于更加專注軟件設計；
• 清晰地了解軟件的需求；
• 很好的詮釋了代碼即文檔。

?之前一直對于測試都是一個籠統的認知，覺得測試僅僅是一種驗證，類似于部分企業中一些比較省事的測試方法，通常在代碼寫好之后再實施測試工作，用于驗證developer的代碼是否符合需求。稍微了解TDD、BDD之后才發現，測試不僅僅是一種對于代碼的驗證，找出幾個bug或者一些諸如壓力測試、負載測試，更是一種約束，一種規范，是與項目需求息息相關，還需要溝通協調客戶、開發人員以及QA，從而幫助更加高效的完成軟件設計開發工作。

從圖中可以發現，最下面的是單元測試（白盒測試），主要用于測試開發人員編寫的代碼是否正確，這部分工作都是開發人員自己來做的。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。再往上，就是BDD（灰盒測試、黑盒測試），主要用于測試代碼是否符合客戶的需求，這里的BDD更加側重于代碼的功能邏輯。

　　從左邊的范疇也可以看出，測試的范圍也是逐層擴大，從單元測試的類到BDD里面的服務、控制器等，再到最上層的模擬實際操作場景的Selenium（Selenium也是一個用于Web應用程序測試的工具。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。支持的瀏覽器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。）對于包括UI界面的測試。之前自己有做過這樣的編碼測試工作，通過寫代碼，可以打開IE、FF等瀏覽器，模擬用戶點擊、填寫數據等操作，從而完成一整套的流程測試。整個測試從小到大，從函數、方法、類到功能模塊乃至系統有著一系列嚴謹的體系。

?

再說BDD

　　BDD是一種敏捷軟件開發的技術。它對TDD的理念進行了擴展，在TDD中側重點偏向開發，通過測試用例來規范約束開發者編寫出質量更高、bug更少的代碼。而BDD更加側重設計，其要求在設計測試用例的時候對系統進行定義，倡導使用通用的語言將系統的行為描述出來，將系統設計和測試用例結合起來，從而以此為驅動進行開發工作。

　　BDD的通用語言是一種近乎自然語言的描述軟件的形式。傳統的開發模式中，客戶很難從技術層面理解問題，開發人員很難從業務需求考慮問題，基于這種通用語言形式可以盡可能的避免客戶和開發者在溝通上的障礙，實現客戶和開發者同時定義系統的需求。避免了因為理解需求不充分而帶來的不必必要的工作量。

　　BDD描述的行為就像一個個的故事(Story)，系統業務專家、開發者、測試人員一起合作，分析軟件的需求，然后將這些需求寫成一個個的故事。開發者負責填充這些故事的內容，測試者負責檢驗這些故事的結果。通常，會使用一個故事的模板來對故事進行描述。

?

總結：

1. 客戶不關心測試

• 客戶只關心軟件是否滿足需求.
• Test 是驗證行為(Verification).
  • 只有當軟件存在后才能進行test.
• BDD關注的是specification.
  • BDD 是Design 行為.
  • 由預期的behaviour 驅動, 并逐步地構建功能塊.
• 從Test 到 BDD:
  • 由**test-centric** 視角轉變為**specification-centric** 視角.

2. 客戶不希望編寫specification

• 客戶不必編寫自身問題的解決方案.
• 認知差異(cognitive diversity)
  • 異類的(heterogeneous) 人員在一起工作.
  • 我們可以幫助客戶完成specification.
  • 客戶需要提供需要解決的問題的信息, 并提供具體事例來指導開發流程.

3. DSL: Domain Specific Language.

• 在組內促進了重要問題的溝通(BA,QA,DEV).
• 特征
  • 語言特征(language nature)
    • 具備連貫的表達能力.
  • 受限的表達力(limited expressiveness)
    • 只支持特定領域所需特征的最小集.
  • 專注于特定領域(domain focus)
    • 只有在一個明確的小領域下,才有意義.
• 分類
  • 外部DSL.
    • 通常使用自定義語法(或XML等), 宿主應用會采用文本解析技術, 對外部DSL 腳本進行解析.
      • 例如: 正則表達式, SQL, Awk.
  • 內部DSL.
    • 通用語言的特定用法, 其腳本是具有特定風格的合法的程序.
    • 與外部DSL 的區別: 內部DSL 使用可執行的語言編寫,然后在該語言中解析.
      • 例如: Lisp,Rails.
  • 語言工作臺.
    • 專用的IDE, 用以定義和構建DSL.
• 抽象: 將DSL看做一種處理抽象的方式.
  • 建立抽象的方式是程序庫或框架. 通過命令/查詢式API調用來操作框架.
    • DSL是程序的前端, 提供了不同于命令/查詢式API風格的操作方式.
    • 程序庫成為DSL的”語義模型”.
    • 通常以DSL加程序庫的方式出現.
• API和DSL的核心區別為: DSL 具有語言性.
• DSL的問題
  • 語言噪音. 學習DSL 應該比學習底層模型的代價小.
  • 構建成本. 可維護性是重要的考量.
  • 語言集中營. 分離關注點來讓DSL有清晰的受限范圍; 自行構造應從外部獲得的東西.
  • DSL是”不斷演化,尚未完結”的事物.
    • 遇到不符合抽象的事物,應該修改抽象,讓其更容易的接納新事物.

作者：滬上最強亞巴頓
鏈接：http://www.jianshu.com/p/37946199ee02
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

轉載于:https://www.cnblogs.com/hughes5135/p/7266142.html

總結

以上是生活随笔為你收集整理的BDD 与DSL 入门的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。