可理解的代碼非常重要，測試代碼也是如此。在我看來，優秀的測試代碼，必須做到一個重要的事情就是保持測試邏輯的清晰。一個完整的測試案例通常包括三個部分：
1. SetUp
2. Exercise
3. Verifiy
4. TearDown
一 個測試案例如果能清晰的區分這三個部分，其實已經成功了一半。但是，如果僅僅只是做到這一步，離我們的“可理解的”測試代碼還有些距離。在我看來，要做到 測試代碼的可理解，首先要做到的是使用簡潔清晰的方式表達每個測試案例的測試過程。我們都不希望在一個測試案例中看到一個long long method，因為我們需要去理解，你調用了那么多方法，做了那么多處理，到底是在干啥？當然，我們也不希望看到一個極端情況：一個測試案例中就看到一個 函數調用。這樣做確實做到了測試案例表面上的簡潔，但是，卻失去了表現內部細節的機會。我們需要表述的是測試過程和方法，比如，進行了什么樣的操作，輸入 了什么樣的數據，然后得出了什么樣的結果，和預期結果對比怎么樣等。如果把這些都封裝到一個方法，別人只能理解你可能會做什么，但很難去理解你將如何去 做。其次，在測試案例fail的時候，能夠清晰準確的定位問題。極限情況下，一個測試案例里應該只能有一個斷言，或者說一個檢查點。測試粒度的縮小能夠加 快問題的定位。通常，當一個測試案例fail的時候，我們還需要定位到底是測試代碼的問題還是被測代碼的問題。這是一個煩人的過程，定位問題的人不一定就 是寫這段測試代碼的人，就算是寫這段測試代碼的人，也需要時間去理解測試案例干了什么。這時，測試過程及方法的清晰表述就變得尤為重要。
有的人會 想到通過文檔來表述測試過程和方法，在我看來，這不是一個好辦法。敏捷開發中的一個思想：“一個過時的文檔比沒有文檔更加糟糕”。為什么需要文檔才能表述清楚你的測試過程？ 只能說明你的測試代碼足夠糟糕，無法讓人理解。一個糟糕的代碼就算當初寫下了足夠詳細的說明文檔，隨著時間的交替，人員的變更，代碼的修改維護，復雜的文 檔和代碼會變得越來越不同步。導致的結果將會是代碼越來越糟糕復雜，文檔越來越過時。最好的文檔，其實是代碼。
我們先來看一下一個老外寫的完整的測試案例代碼：
@Test
public?void?shouldBeAbleToEditAPage()?{
????Given.thatThe(wiki).wasAbleTo(beAtThe(PointWhereItHasBeen.JUST_INSTALLED));
????And.thatThe(user).wasAbleTo(navigateToTheHomePage());

????When.the(user).attemptsTo(changeTheContent().to("Welcome?to?Acceptance?Test?Driven?Development"));

????Then.the(textOnTheScreen().ofThe(user)).shouldBe("Welcome?to?Acceptance?Test?Driven?Development");
}
我 之前并沒有為這個測試案例做任何說明，相信每個看過這個測試案例的人都能非常容易的理解這個測試案例的行為，甚至是對代碼不通的人。因為上面的測試代碼使 用了幾乎是自然語言的方式，描述了其測試的過程。了解的人一定看出來了，其實，這就是行為驅動開發，Behavior Driven Development，簡稱：BDD。

行為驅動開發(Behavior Driven Development)

Behaviour-Driven Development (BDD) is an evolution in the thinking behind TestDrivenDevelopment and AcceptanceTestDrivenPlanning.

It brings together strands from TestDrivenDevelopment and DomainDrivenDesign into an integrated whole, making the relationship between these two powerful approaches to software development more evident.

It aims to help focus development on the delivery of prioritised, verifiable business value by providing a common vocabulary (also referred to as a UbiquitousLanguage) that spans the divide between Business and Technology.
BDD 使用幾乎近于自然語言的方式描述了軟件的行為過程，因此，可以直接作為軟件的需求文檔，也可以直接應用到測試中，作為測試的標準文檔。我們在做單元測試 時，經常是針對某個函數，或是某個類進行測試，但是被測函數或是被測的類是可能經常變化的，我們的測試案例也需要經常性的隨之變化。然后，BDD描述的是軟件的整個系統行為，幾近于需求文檔，可變性大大減小。因此，測試案例不需要做太大變化。同時，這樣的測試案例最貼近于需求，貼近于實際的系統行為。
BDD描述的行為就像一個個的故事(Story)，系統業務專家、開發者、測試人員一起合作，分析軟件的需求，然后將這些需求寫成一個個的故事。開發者負責填充這些故事的內容，測試者負責檢驗這些故事的結果。通常，會使用一個故事的模板來對故事進行描述：
As?a?[X]
I?want?[Y]
so?that?[Z]
同樣的一個故事，可能會有不同的場景。通過上面的模板描述了故事之后，再通過下面的模板對不同場景進行描述：
Given?some?initial?context?(the?givens),
Whenan?eventoccurs,
then?ensure?some?outcomes.
一個經典的例子就是ATM取款機的例子。故事的描述為：
Title:?Customer?withdraws?cash
As?a?customer,
I?want?to?withdraw?cash?from?an?ATM,
so?that?I?don’t?have?to?wait?inline?at?the?bank.
作為一個客戶，我去ATM取錢，就不需要去排隊。同樣的故事，會有不同的場景發生：
Scenario?1:?Account?is?incredit
Giventhe?account?is?incredit
Andthe?card?isvalid
Andthe?dispenser?contains?cash
Whenthe?customer?requests?cash
Thenensure?the?account?isdebited
Andensure?cash?isdispensed
Andensure?the?card?isreturned
如果你取款的金額比你的存款還多，將是下面的場景：
Scenario?2:?Account?isoverdrawn?past?the?overdraft?limit
Giventhe?account?isoverdrawn
Andthe?card?isvalid
Whenthe?customer?requests?cash
Thenensure?a?rejection?message?isdisplayed
Andensure?cash?isnot?dispensed
Andensure?the?card?isreturned
有了這樣的故事、場景的描述，測試者可以通過一些BDD的測試框架將上面的故事轉成測試代碼（當然，也可直接由開發來完成，這里說測試者是為了方便理解），開發者實現產品代碼，并保證測試代碼通過。

常見的BDD框架

• BOO - Specter: A tool written for the Boo language, a .Net and Mono programming language.

• C - CSpec

• C++ - CppSpec Spec-CPP

• C# .Net - NSpec

• .Net - NBehave

• .Net - NSpecify (incomplete site)

• Delphi - dSpec

• Groovy - GSpec, http://easyb.org easyb, tspec a non-English BDD framework with Thai syntax.

• Java - JBehave, JDave, beanSpec, Instinct

• Javascript - JSSpec

• PHP - PHPSpec

• Python - Specipy, spec plugin for nose

• Ruby - RSpec, Shoulda, test-spec & bacon, Cucumber

• Scala - Specs

回到正題

剛才就像對一門新的技術或方向進行了了解，再回過頭來想想，BDD對于測試的意義到底在哪。通過上面的了解，我們知道了行為驅動開發并不止是一個測試行為，其實很大意義上是一個產品需求分析人員、開發、測試共同來完成的一個行為。BDD同時也是一個非常理想化的過程，幾乎現在大部分的公司連TDD都實現不 了。作為測試人員，我們不是要去抱怨，我們應該慶幸作為測試開發人員，我們有機會使用最前沿，最先進的技術去解決問題。開發不能做到TDD，我們可以對自己的測試代碼實施TDD，我們可以嘗試各種不同的語言，然后選擇最優雅的方式去實現。同樣的，我們可以使用BDD所使用的自然語言描述方法來編寫我們的測試案例。這其實才是我本文的關鍵所在。
使用行為驅動開發，還需要打破傳統的魄力。因為之前幾乎沒有人會告訴你一個函數的命名為ShouldXXX()，也不會有有When, Then，And之類的類或函數。當你習慣它，會變得非常好玩。
使用行為驅動開發，可以使我們的案例描述邏輯更加清晰，可以想象以后維護你的代碼的人會對你大贊一番，因為省去了他理解代碼的大部分時間。
使用行為驅動開發，可以建立自動化測試與手工系統測試的橋梁。或許可以形成這樣的模式：手工測試人員負責設計故事和場景，自動化測試人員負責實現故事和場景。通過這樣的聯系，手工測試人員能夠更好的了解到自動化測試所做的內容，從而免去不必要的重復勞動。
使用行為驅動開發，可以使你的測試更加貼近實際的用戶行為，從而找到系統的問題所在。

沒有銀彈

《沒有銀彈》（No Silver Bullet）是IBM大型電腦之父佛瑞德·布魯克斯（Fred Brooks）在1987年所發表的一篇關于軟件工程的 經典論文。該論述中強調由于軟件的復雜性本質，而使真正的銀彈并不存在；所謂的沒有銀彈是指沒有任何一項技術或方法可使軟件工程的生產力在十年內提高十 倍。剛才提到的使用行為驅動開發的種種好處，但是，如果運用不當，往往會適得其反。我們使用When，Then之類的連詞作為函數，并不是說可以隨意根據 需要隨意的命名。比如，使用This或These作為函數名，其行為就應該是返回一個或多個對象，而不是做其他的事情。可以想象，如果一個函數的名稱是 These，里面執行的確實一個文件拷貝的操作，對于代碼的維護者來說是多么糟糕的一件事情啊。
其實我對行為驅動開發也只是初略的了解，本文表達的是僅僅是我個人的一些思想，如有錯誤之處也希望大家能夠指出。最后，我希望達到的是：

優美的測試代碼，就是一個個優美的故事。

本文參考資料：
http://behaviour-driven.org/
http://dannorth.net/introducing-bdd
http://www.javaworld.com/javaworld/jw-09-2008/jw-09-easyb.html

轉載于:https://www.cnblogs.com/coderzh/archive/2009/07/26/1531633.html

總結

以上是生活随笔為你收集整理的优美的测试代码 - 行为驱动开发(BDD)的全部內容，希望文章能夠幫你解決所遇到的問題。

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