原文鏈接：https://joven.site/PreliminaryStudyOnTestDesign/

測驗設計的初探

1. TDD：測驗驅動開發（Test-Driven Development）
2. BDD：行為驅動開發（Behavior Driven Development）
3. ATDD：驗收測驗驅動開發（Acceptance Test Driven Development）
4. DDD：領域驅動開發（Domain Drive Design）

通過下面一幅圖就可以發現對于測驗也有不同的層次和流程：

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

　　從左邊的范疇也可以看出，測驗的范圍也是逐層擴大，從單元測驗的類到BDD里面的服務、控制器等，再到最上層的模擬實際操作場景的Selenium（Selenium也是一個用于Web應用程式測驗的工具，Selenium測驗直接運行在瀏覽器中，就像真正的用戶在操作一樣，）對于包括UI界面的測驗，

TDD

TDD指的是Test Drive Development，很明顯的意思是測驗驅動開發，也就是說我們可以從測驗的角度來檢驗整個專案，大概的流程是先針對每個功能點抽象出介面代碼，然后撰寫單元測驗代碼，接下來實作介面，運行單元測驗代碼，回圈此程序，直到整個單元測驗都通過，這一點和敏捷開發有類似之處，

它是一種測驗先于撰寫代碼的思想用于指導軟體開發，測驗驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方法論，TDD的原理是在開發功能代碼之前，先撰寫單元測驗用例代碼，測驗代碼確定需要撰寫什么產品代碼，

TDD的好處自然不用多說，它能讓你減少程式邏輯方面的錯誤，盡可能的減少專案中的bug，開始接觸編程的時候我們大都有過這樣的體驗，可能你覺得完成得很完美，自我感覺良好，但是實際測驗或者應用的時候才發現里面可能存在一堆bug，或者存在設計問題，或者更嚴重的邏輯問題，而TDD正好可以幫助我們盡量減少類似事件的發生，而且現在大行其道的一些模式對TDD的支持都非常不錯，比如MVC和MVP等，

但是并不是所有的專案都適合TDD這種模式的，我覺得必須具備以下幾個條件，

• 需求必須足夠清晰
• 程式員對整個需求有足夠的了解

如果這個條件不滿足，那么執行的程序中難免失控，當然，要達到這個目標也是需要做一定功課的，這要求我們前期的需求分析以及HLD和LLD都要做得足夠的細致和完善，

其次，取決于專案的復雜度和依賴性，對于一個業務模型及其復雜、內部模塊之間的相互依賴性非常強的專案，采用TDD反而會得不嘗失，這會導致程式員在拆分介面和寫測驗代碼的時候作業量非常大，另外，由于模塊之間的依賴性太強，我們在寫測驗代碼的時候可能不采取一些橋接模式來實作，這樣勢必加大了程式員的作業量，

• 特點

1. 有利于更加專注軟體設計；
2. 清晰地了解軟體的需求；
3. 很好的詮釋了代碼即檔案，

• 相關文章

1. 初步認識TDD:https://www.cnblogs.com/wfsovereign/p/4198209.html
2. TDD和BDD及DDD的解說:https://blog.csdn.net/bennes/article/details/47973129
3. TDD 已死？讓我們再聊聊TDD:http://blog.jobbole.com/110560/

BDD

• 特點

1. 縮小團隊成員之間溝通差距
2. 促進對客戶需求的理解,并促進對實際需求的持續溝通

Behavior Driven Development，行為驅動開發是一種敏捷軟體開發的技術，它鼓勵軟體專案中的開發者、QA和非技術人員或商業參與者之間的協作，

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

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

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

# 關鍵字：
# Feature(功能)
# Scenario(場景)
# Given(假如), When(當), Then(那么), And(而且), But(但是)[Steps]
# Background (背景)
# ScenarioOutline(場景大綱)
# Examples(例子)

# example：

Feature: calculator
    In order to avoid silly mistakes
    As a math idiot
    I want to be told the sum of two numbers
@mytag
Scenario: Add two numbers
    Given I have entered 50 into the calculator
    And I have entered 70 into the calculator
    When I press add
    Then the result should be 120 on the screen

# 中文例子：

功能: 計算器
    為了避免愚蠢的錯誤
    作為一個數學白癡
    我想知道兩個數的和

@mytag
場景: 添加兩個數字
    假如 我已經輸入了第一個數50到計算器
    而且 我已經輸入了第二個數70到計算器
    當 我點擊求和
    那么 結果應該顯示120

常見的BDD框架：

• C – Cspec
• C++ – CppSpec, Spec-CPP
• .Net – NBehave, NSpecify, SpecFlow
• Groovy – GSpec, easyb, Cuke4Duke
• PHP – PHPSpec
• Python – Specipy
• Ruby – RSpec, Shoulda, Cucumber

與Java相關的BDD測驗工具：

1. JBehave – Java annotations based, Test frameworks agnostic
2. Cuke4duke – Cucumber support for JVM
3. JDave – RSpec (Ruby) inspired, Mojo 2 & Hamcrest based
4. beanSpec – Java based
5. easyb – Java based, Specifications written in Groovy
6. instinct – BDD framework for Java, providing annotations for contexts. Inspired by Rspec
7. BDoc - Extracts behaviour from unit tests

來自Leo_wlCnBlogs：https://www.cnblogs.com/Leo_wl/p/4780678.html

HLD & LLD (High Level Design & Low Level Design)

• HLD：高層次設計High Level Design,概要設計
• LLD：低級別設計Low Level Design,詳細設計

1. 高層次設計（HLD）是整個系統的設計-包括系統架構和資料庫設計， 它描述了該系統的各個模塊和功能之間的關系， 資料流，流程圖和資料結構下HLD覆寫，
2. 低級別設計（LLD）就像是詳細的HLD， 它定義了用于該系統的每個部件的實際邏輯， 類圖與類之間的所有方法和關系， 程式規范是根據LLD覆寫，

.net下的測驗框架及相關庫

1. xUnit.net是一個免費的，開源的，以社區為中心的.NET Framework單元測驗工具，
2. MSTest是微軟自己寫的一套開源的,測驗工具,目前是V2版本.Github:https://github.com/Microsoft/testfx
3. NUnit是所有.Net語言的單元測驗框架，最初從JUnit移植，當前的生產版本3已經完全重寫了許多新功能并支持各種.NET平臺，
4. SpecFlow是一個可以將業務需求系結到.NET代碼的工具,并且開源,用于管理和自動執行人類可讀的驗收測驗.是Cucumber家族的一部分.
5. Shouldly是一個斷言框架，它專注于在斷言失敗時提供很好的錯誤訊息，同時簡單而簡潔，Github:https://github.com/shouldly/shouldly
6. Cucumber是一種支持行為驅動開發（BDD）的工具，遵循Gherkin語法規則.

例子：https://github.com/mainxx/100DaysOfCode/tree/master/%23001

• 相關文章

1. 舍棄Nunit擁抱Xunit:https://www.cnblogs.com/cuiyansong/p/4521124.html
2. BDD原則與實踐:https://docs.cucumber.io/bdd/

關于ATDD及DDD.下次再探索

5 BDD Tools for C# Codebases

C#五大流行BDD工具介紹：https://blog.gurock.com/5-bdd-tools-c-codebases/

1. SpecFlow
2. NSpec
3. MSpec
4. BDDfy
5. ApprovalTests

最后，您使用哪種特定工具并不重要，更重要的是您開始使用有意義的測驗流程，BDD是一個強大的工具，可以讓業務，測驗人員和開發人員就軟體的完成意義達成一致，

標籤：其他

上一篇：#2018年中總結之二#專案問題淺思 領域驅動設計?敏捷開發?

下一篇：Git - git tag - 查看當前分支 tag 版本&說明