測試驅動開發與行為驅動開發中的測試先行方法

Test-First是一個很優秀的工具。它能促進團隊內更好的理解力和生產力。其結果是高質量的代碼——無論是早期成功發現 bug還是正確實現特性方面。

（……）今年我們的主題是親身實踐敏捷。我們知道沒有老師能夠傳授親身體驗，因此我們舉辦了很多研討會和實用講座，會議參加者可以親身體驗、聽到和看到敏捷活動是如何在許多成功企業內實施的。

Zilberfeld：測試驅動開發是從90年代末的極限編程從業者開始的。但事實上，人們在編寫代碼的數十年前已經開始編寫測試了。

其理念是這樣的：當程序員編寫代碼時，他們通常在代碼中解決復雜問題。但是，這種方式常常使得結果同樣復雜，并且含有遠遠超過實際需要解決的問題（假設重要的東西已經被編碼）。

這意味著需要測試更多的代碼。測試有時需要改變“已經工作”的代碼，這會引入風險。最終導致要么根本沒有進行測試，因為沒有時間測試，或者是次優的測試，因為無法覆蓋我們想要覆蓋的范圍。

測試先行定義了工作需求。因為我們有測試形式的定義，它定義了為了解決具體問題我們需要編寫什么樣的代碼。僅僅通過運行測試就可以非常簡單地知道我們是否有可工作的功能。

這種方式會擴大測試覆蓋率，因為測試成為優先開發活動，而不會被迫推到最后。

另外，編寫這些測試和制定場景的時候，我們會更深入地探索問題空間，因為會出現許多問題。而在事后測試（test after）中，有時不會發生這些討論，開發人員以他們的思維編碼，而不是以解決方案的需求編碼。

Zilberfeld：在 TDD和 BDD中，你先將問題分解成多個情境，也就是例子。我們的頭腦更容易專注小情境，而不善于解決大的、復雜的問題。

然后開始著名的紅-綠-重構循環，就像這樣：

• 編寫一個失敗的情境。失敗是因為編譯或者因為代碼不存在。無論如何，該測試是代碼如何被外部模塊使用的案例。
• 努力讓測試通過。重點是可工作的功能而不是形式，也就是編寫最小的實現，讓它通過測試。更進一步，它應該通過迄今為止我們編寫的整個測試套件。
• 改進代碼。現在一切都是綠色的，使用測試安全網我們可以重寫代碼。如果我們破壞了什么，我們會立即知道。

將問題分解成更小的部分，然后以增量的形式開發需要的代碼，并且在流程中加入急需的剎車。這有助于我們思考我們遺漏的情境，而不是“我們知道解決方案是什么樣子”。

BDD開始于2000年代中期，更進一步地將 TDD推向產品空間。通過使用產品用途案例，我們可以僅僅開發情境所需的代碼。我們可以專注對業務重要的情境。然后可以使用 TDD編寫實際代碼。

BDD最大的優勢是溝通。如果你將“三個同伴”——業務分析師、開發人員和測試人員——集中到一個房間，討論我們希望看到的行為案例，那么在編寫代碼之前，我們將會得到最好的提出和解決問題的觀點。

而這就是 BDD——討論商定的行為案例。這些案例可以寫成自動化測試（但這不是要求），然后編碼使測試通過，最后重構代碼。

顯然，BDD情境的詳細程度比更精細的 TDD測試還要寬泛。盡管我發現在某些方面它們是相互關聯的，但是在 TDD和 BDD情境中編寫測試還是需要不同的技能。

Zilberfeld：在 BDD中，由誰編寫情境是有區別的，但是我合作的大多數團隊中，都是測試人員編寫情境。這些案例的討論通常在編寫代碼之前。測試人員和開發人員并行工作——測試人員專注高水平的自動化測試，開發人員專注代碼和單元測試（測試優先與否）。一旦完成就會對情境進行評審。然后在某個時候對開發和測試進行集成，以確保測試通過。

BDD和 TDD在迭代中非常“敏捷”，這使得情境“完成”與否非常的明顯。BDD情境要么“符合”迭代，要么就是故事過于冗長。

在實現上 TDD稍有不同。培訓之后，開發人員會對等待他們的代碼妥協。通常這些都是遺留代碼，這與干凈的測試先行代碼不同。

我常開玩笑說 TDD中最后一個 D是紀律。因為它對測試先行的實現最重要。它與我們被教導的不同也更難，因此在看到價值之前我們需要團隊的支持。這就是為什么大部分團隊最終不做 TDD，勉強接受事后測試的緣故。

熬過困難的前期之后，開始清理自己的代碼，添加更多的覆蓋率。代碼變得更加容易維護。并且從社會角度來看，新加入團隊的開發人員會帶著“這就是我們的工作方式”理念加入 TDD。這是一個正面的反饋循環。

Zilberfeld：這次研討會背后還有一個故事。幾年前，我打算在比利時 Testing Days會議上舉辦“TDD a spaceship”研討會（我打算三月在荷蘭的 Agile Testing Days會議上舉辦）。它是為開發人員設計的，但是參與者都是測試人員，擁有極少的編碼經驗。因此研討會變成解釋測試先行的理念，并且是在沒有實際編碼的情況下。很自然地，我被吸引到星球大戰的例子，我們交談、做課堂筆記，并討論了驗收標準，以及如何知道故事已經完成。

那次研討會之后，我考慮如何以一種經驗的方式實現它。碰巧，我被介紹給GIF制作軟件工具，突然之間我們有了能夠幫助的工具。這是一個創建型工具，人們可以提前寫電影“腳本”，構建并運行，并能夠立即獲得反饋。

很棒的是我們可以應用敏捷開發原則和經驗。因為你所想象的電影樣式跟實際結果總是會有出入，所以我們構建了一個新的版本。

另一個案例是處理遺留代碼。其中一個練習是在電影中更換演員，但是因為電影已經編輯，因此我們只能在開頭或者結尾添加場景。鑒于需求與代碼不能分開考慮，如何更改需求與已經構建完成的代碼之間的沖突這一理念就非常有啟發性。

Zilberfeld：這是我們第五年舉辦該會議，自創立以來無論是規模還是質量都得到了提升。它被列為以色列最好的敏捷會議是因為：

我們圍繞“親身實踐”主題會議。我們將有全天的專題報告、小型研討會，甚至演講都具有實際用途。我們旨在讓人們親身體驗，然后回歸工作，開始實施他們學到的內容。

我們為不同類型的參與者準備了內容——Scrum Master，測試人員，開發人員，產品經理，團隊領袖等任何你能夠想到的。但是，該會議不僅僅是拓寬你的角色知識。它是以一種“親身實踐”的方式讓你學習別人如何做的。